engineering
How do I design for future fields I don’t know yet without overengineering?
Forum Discussion
MarkShnier__You
Qrew Legend
Qrew LegendI 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.
