That got a bit more complicated than I thought because the data, while in Book 6 Scouts is in a single table, in the database it is in two tables for the whole 3rd normal form standard. Yes, proper database stuff to help reduce duplicate data and all that fun stuff.
Each roll is independent from other rolls. We have the "basic system nature" (aka solo, binary or trinary). The next step, 10B, is primary star type and size. While I think that should be two rolls, each with the same DMs, it is not entirely clear in the check list. Currently I've just hardcoded B0 and Ia because I know I have that data set up. Data entry for the zones is annoying, so I really need to figure a better way of handing it. Plus, I really don't have the edit capacity for zones once you add them. I need to work on that as well.
Anyway, I currently use a DTO (Data Transfer Object) to collect the data from both tables, but not I realize that if it is 2 separate rolls, I don't need to do that. I'll revisit the logic for that.
But we do have the primary stellar type now, and we set the main planet's orbit to be the habitable zone for that type of system. And I also just now realized I also need to add the stellar zone to the system data, as that will also let us know all the orbits. Why this is a pretty iterative process as I go through all this.
 |
a solo system |
 |
habitable orbit set in the main world |
Next steps are to revise the schema for the stellar system: while I have the stellar type in there, that table really only has 2 pieces of info, the size (Ia) and description (Bright Super giant). Though since we do have that ID (that is the list of stellar types in the 1st screenshot) we
do have all the zones as each zone has stellar type ID.
And in looking at those tables in Book 6, I may redo the data schema. Rather than a lot of nearly identical data, we can turn this sideways and have orbits that have a list of stellar types and the zone. And star types (A0, A5, etc). Not quite there yet but I think I can greatly reduce data entry and what is essentially duplicated data just for different sizes.
For instance, we can have 3 orbit 8 records: I / H / O for inner, habitable, outer orbit. Then we have a table that has the stellar size ID (Ia for instance), the stellar type ID (say B0), and it would have records for 8..12I, 13 H and 14 O.
It probably does not make sense to anyone but I'm going to let that stew in my head. It would complicate a few things but greatly reduce data entry in some ways. If you look at
update 20 the screenshot with the zones for the stellar type (and now it is misnamed but as I said way back, I get confused over some of the terminology) there is a row per orbit. The 1st row for orbit 8 is the same for ALL the sizes for a B0 type star. Basically, repeating the same data. We really only need a single "orbit 8, Inner zone" record that we can use for all those that are like that. We'd need an "orbit 8, Habitable zone" record for size II A5, F0, F5, G0 and G5 stars. That sort of thing. And there is something bumping in the back of my head that says I may be able to reduce this even more.
Yes, what goes on behind the scenes in software and database stuff can be very confusing to those who are not used to it. And confusing to those who are used to it as well!
No comments:
Post a Comment