engineering
How do I design for future fields I don’t know yet without overengineering?
Forum Discussion
MarkShnier__You
Qrew Legend
Qrew LegendYou don't need to plan ahead for future fields. You just make the fields as you need them. What is very important to get right is designing which tables you need and their relationships.
One thing you definately want to avoid is any concept of fields that are like [Sales 2026] where the field is hard coded for data entry or built in a summary field for a particular year. That would indicate poor design which can be improved. You want to never design an app that will need annual maintenance to roll over to a new year.
That makes sense—prioritizing the table structure and relationships over trying to predict every future field.
From a schema design perspective, how do you usually decide whether something deserves its own table versus staying as a field on an existing table, especially when requirements are still evolving?
For example, are there common signals that tell you:
- “this is just a new field,” versus
- “this should really become a related child table or normalized entity”?
I’m trying to avoid both under-modeling early on and having to refactor a heavily used app later.
