When to create a table instead of a field
The table or field decision looks minor and determines how far a system can grow. A field holds a value. A table holds a thing that has its own attributes, its own history and its own relationships. Choosing wrongly is the most common structural mistake in internal systems.
Why the wrong choice surfaces late
Storing a supplier name as text works perfectly until you need the supplier's payment terms, or a list of everything bought from them, or to correct a spelling in one place.
By then the text exists on thousands of records, and fixing it is a migration rather than a change.
Signals you chose wrongly:
- The same value typed repeatedly across records
- Needing a second field to describe the first
- Reports grouping incorrectly because of spelling variants
- Wanting to see everything related to one value
- Needing to change a value everywhere at once
Tests to apply
| Test | Field | Table |
|---|---|---|
| Does it have its own attributes? | No | Yes |
| Does it repeat across records? | Rarely | Often |
| Would you want its history? | No | Yes |
| Does it relate to other things? | No | Yes |
| Is it a fixed short list? | Single option field | Not needed |
Step by step to decide
- Ask whether it has attributes of its own, which is the strongest signal.
- Ask whether it repeats, since repetition means it is an entity.
- Ask whether you would want its history.
- Use a single option field for short fixed lists like status.
- Use a table for anything real in the world, such as a person or a company.
- When uncertain, prefer the table, since promoting later is harder.
- Check the model before building interfaces.
Why the bias should be toward a table
Converting a text field into a table later means migrating data and rebuilding everything that referenced it. Creating a table you did not strictly need costs a slightly more complex model. The asymmetry is large enough that uncertainty should resolve toward the table.
Why choose Jestor
In Jestor, tables are relational with connected fields in both directions, so promoting a concept into a table and referencing it is straightforward. Single option and tag fields cover short controlled lists, and formulas can calculate across connected tables when the model is right.
Frequently Asked Questions
What is the clearest sign something should be a table?
That it has attributes of its own beyond its name. See jestor.com.
When is a single option field enough?
For a short fixed list such as status or priority, which has no attributes.
What should I do when unsure?
Prefer the table, since converting a field later is much harder.
Video Tutorial: Step by Step
With Jestor, you can automate workflows, connect teams, and build internal systems your way, all without code and powered by AI. Discover Jestor at jestor.com and see how to take your company's operations to a new level of efficiency and control.