> ## Content Index
> Fetch the complete content index at: https://blog.jestor.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# When to create a table instead of a field
- URL: https://blog.jestor.com/table-or-field-how-to-decide/
- Published: 2026-09-16T18:55:24.000Z
- Updated: 2026-09-16T18:55:24.000Z
- Author: Bruno Bannach

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

1. **Ask whether it has attributes of its own**, which is the strongest signal.
2. **Ask whether it repeats**, since repetition means it is an entity.
3. **Ask whether you would want its history**.
4. **Use a single option field** for short fixed lists like status.
5. **Use a table** for anything real in the world, such as a person or a company.
6. **When uncertain, prefer the table**, since promoting later is harder.
7. **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](https://www.jestor.com/?ref=blog.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](https://www.jestor.com/?ref=blog.jestor.com) and see how to take your company's operations to a new level of efficiency and control.