engineering
How do I design for future fields I don’t know yet without overengineering?
Forum Discussion
4 Replies
- MarkShnier__You
Qrew Legend
I would say the main clue is when you start making multiple fields to hold very similar data. For example, you make a file attachment field and then you say well maybe they want to upload three documents so I'll go file attachment one file attachment two and file attachment three. This is a very expedient to do on the parent record, but inevitably someone is gonna come along and say well I have four documents to upload to this project record.
Then you realize it would've been better to have a child table of documents and that way you can categorize the documents and you don't really care how many they upload.
The same thing might hold through for a project notes field. At first, you think I'll just give them a note field and they can do updates. But then you realize you really wanted to track who made the note and when and in what sequence so you realize it would be better to have a child table for project notes. Having a trial table, also gives you more granular control over which users can view an update the records.
for example, going back to the earlier example of a trial table for documents, perhaps some document types are more confidential than others. So based on the document type, you can restrict access.This is a really useful rule of thumb—the repeating field pattern is a great example of when a design starts signaling that it wants a child table instead.Beyond repeatable data like attachments, notes, or line items, are there other common architectural signals you watch for that suggest “this should become its own table”?
For example, do factors like permissions, reporting complexity, workflow stages, or audit history usually influence that decision for you as well?I’m trying to build stronger instincts around when to normalize early versus when to keep things simple until the app proves the need.
- MarkShnier__You
You 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.
