We now have a new point to bring to the debate, though.
The primary improvement would be that it would stop me from having to maintain duplicate architectures for more than 25 different custom databases. Once we get to that point, it really becomes a more universal kind of data field and shouldn't be duplicated. It's not good architectural design to have a database that has these fields copied into all these different areas. It makes maintenance much more difficult, too. If we change something, I'd have to go and change it in 25 places, affecting a lot of different areas.
There may be a compromise, though. We currently have 2 main categories of data fields:
1) Primary Data Details (Affects all plants)
2) Specific custom details (affects just the plants in each custom database)
We could add a third one that is common to all plants, and called something like "Registration and Genetics" or something like that. In there we can include the parentage details, hybridizer, introduced date, registrar link, GMO/Hybrid/OP/etc, and so forth.
That would keep all those paperwork type details in one area that is uniform across the database.
