Am I being a bit dumb, or is making a database that has more than 1 table a Herculean Labour?
Scoundrels, Crews and Contacts.
A Scoundrel is in 1 Crew.
A Crew has 0+ Scoundrels.
Contacts are known to individual Scoundrels and/or Crews. A Contact has a Rating (Friend/Neutral/Hostile) with each Scoundrel/Crew.
I need to call each and every combination.
How complicated is this meant to be, as I seem to be making a pig's ear of the whole thing!
I did build a 1-to-many ScoundrelWithCrew, but then it seems I needed a Nested Relationship (ScoundrelAndContacts)WithCrew (and somehow add ContactRating).
And I need to replicate it all for focussing on Crews. Repeat: Contacts.
Do I really have to have all these cross-ref tables, classes, combined entities? And if so, is there a good way to organise and keep track of them?
And how do I pass it all to the Domain/UI?
@ArmouredWizard I'm not familiar with Kotlin or Android dev but it does sound like you're making the database overly complex. (Edit: or maybe I'm lacking in reading comprehension)
@kevin I don't have my current schema to post.
It's not fully built yet, as I keep running into new problems as I add more to it.
I suspect it all needs rebuilding from scratch anyway.
@ArmouredWizard@kevin In an RDBMS it should look something like this. Yes there are a lot of tables (which is why a NOSQL solution for RPG stuff is often easier to work with).
@ArmouredWizard@kevin It depends on the platform. The best known are document databases like MongoDB. I assume there are Android equivalents. Typically it would be all JSON.
@rivetgeek There are NoSQL for Android.
I have briefly looked at remote Firebase, but I want to stay local for now.
I'm not sure what benefits NoSQL has
@ArmouredWizard It's not relational and there are no data types, so the data can be structured a lot more flexibility. Everything is self contained. So for example a scoundrel record in a NOSQL DB would contain everything needed for that scoundrel record. Even the contact name, their status, the crew name, etc., all nested in the JSON. It might have a reference to the a actual contact record that is its own document.
@rivetgeek@ArmouredWizard Since they are one-to-many, you could even simplify this further by getting rid of scoundrels_crews and giving a scoundrel a crew_id.
@kevin@ArmouredWizard I always overengineer on the basis of the fact that a developer will tell me there's a one-to-many relationship, and then come back sometime after deployment and say, "Oopsie, we need many-to-many".
@rivetgeek Yeah, it might be necessary down the line to scale. It could be a good option to minimize complexity now... or not! I think the likelihood of a PC belonging to multiple parties is so low that @ArmouredWizard could safely assume 1-to-M. Then again, that could be someone's use case.
@rivetgeek@kevin I think I'll be keeping Scoundrel/Crew as 1-to-many this time.
I'll have other many-to-many relationships, to test my skills, so some variety will be good! :)
Add comment