Column or table in an ERD? If it can repeat, it is a table

One test: can there be more than one?

An ERD is a drawing of what a service manages and how those things connect. It stands for Entity Relationship Diagram; each thing you manage (an entity) becomes one table in the database, much like a spreadsheet. A vertical slot in the table is a column, and a horizontal row is one record.

The lecture uses a mobile wedding invitation service. An admin logs in and creates invitations. The things being managed here are two: admins and invitations. Title, date, venue, message, groom's name and bride's name are not separate things to manage but attributes of the invitation, so they become columns of the invitation table.

The service does well, so a feature gets added: guests can leave a congratulatory message like 'Congratulations'. Messages need to be written, edited and deleted. Could they be attached as a column on the invitation table?

If each invitation carried exactly one message, yes. There would be no need for a separate table. But one wedding gets messages from many guests. One slot holds one value, so that approach cannot work. The messages go into their own table, connected to invitations by a line.

That is the instinct the lecture stresses. If a value exists only once, it is a column; if several can appear, it is a table. Every time you add a feature, first ask how many of this value one thing can have.

[If only one] one column on the invitations table
id  title                 greeting
1   We're getting married  Congratulations

[If many] a separate greetings table
id  invitation_id  content
1   1              Congratulations
2   1              Be happy together
3   1              Best wishes to you both

1:N, parent and child — reading the symbols at the line ends

Most relationships between tables are 1:N, meaning many attached to one. One admin creates many invitations, and one invitation collects many messages. Both are 1:N.

The one side is called the parent and the many side the child. An invitation looks to the single admin who created it, so the admin is the parent and the invitation the child. The child table carries a column holding the parent's id: admin_id on the invitations table, and invitation_id on the greetings table in the example above, are such slots. A column pointing at a row in another table like this is called a foreign key.

In an ERD you draw a line between two related tables and show counts by the shape at each end. The one side gets a bar; the many side gets a line end that splits into three prongs. It looks like a bird's foot, hence the name crow's foot notation.

Whether something must exist goes in the same spot. A bar means it must exist; a circle means it may be absent. An admin may not have made any invitation yet, so the invitation end shows a circle together with the three prongs. Conversely, an invitation never exists without an admin, so the parent end is usually two bars.

Of the two symbols at a line end, the one closer to the table gives the maximum count and the one farther from it (toward the middle of the line) gives the minimum. Reading just these symbols on an ERD an AI draws for you shows what the service allows.

Admin      ||--o{ Invitation   one admin, zero or more invitations
Invitation ||--o{ Greeting     one invitation, zero or more messages
Invitation ||--o| LiveStream   one invitation, zero or one link

Splitting out a single value — optional 1:1

Next comes live streaming. It is a paid service that broadcasts the ceremony for guests who cannot attend in person, so some couples sign up and some do not. One wedding has either no live link or one. There is no need for several.

This is a 1:1 relationship, and since it may be absent, an optional 1:1. If live streams get their own table, the invitation end is drawn with two bars and the live stream end with a circle and a bar.

The lecture, though, says there is no real need to do that. Add one link column to the invitation table and fill it only for those who signed up. The value exists at most once, so by the earlier test it is a column.

The case for splitting it out is when the slot is empty too often. If one couple in ten signs up, the other nine rows leave that slot blank. The lecture explains that when blanks pile up like this and you want to manage it more efficiently, you may split it into a 1:1 table. It is not the mainstream usage, though. Remember 1:1 as an option; the default is a column.

[Default] one column on the invitations table
id  title                 live_stream_url
1   We're getting married  (empty)
2   A spring promise       https://live.example.com/abc

[Option] a separate live_streams table
id  invitation_id  url
1   2              https://live.example.com/abc

When the template enum becomes a table

In the first design, templates were fixed at three: 1, 2 and 3. A data type that accepts only preset values and raises an error for anything else is called an enum. It works the same way as limiting login methods to Kakao, Google and Apple.

Now say the template designs fall short, so you hire a new designer and want to keep adding templates. At first you edit the code to add number 4, then number 5, then drop number 1. When that keeps happening, touching the code or the database every time becomes a chore.

At that point you turn templates into a table of their own. Each template gets its own id (a UUID, an ID string generated so it never collides), and the invitation carries a template_id column instead of the enum column. template_id points at the id in the templates table. One template can produce many invitations, so templates and invitations are 1:N, with the template as parent.

The takeaway from the lecture is this: even a value fixed to a few options can move from a column to a table once it needs managing. If additions and removals have become frequent, that value is no longer an attribute but a thing you manage. Moving the 1, 2 and 3 values already stored on invitations over to the new ids takes care, though, and that is covered in part 04.

Something to try today: ask an AI to lay out your current project's table structure and go through it with the request below. Next time we look at the many-to-many case where several admins manage one invitation together, how to resolve it with an intermediate table, and how to ask an AI to draw an ERD with Mermaid, a tool that turns text written as code into a diagram.

[Before] invitations — template is an enum
id  title                 template
1   We're getting married  template_1
2   A spring promise       template_2

[After] templates table + template_id
templates
id    name
t-01  Classic
t-02  Floral

invitations
id  title                 template_id
1   We're getting married  t-01
2   A spring promise       t-02

Lay out the database tables and columns of this project as a table.
Then find these three things:
1. Places where a value that can repeat is stuffed into a single column
   (e.g. numbered columns like greeting1, greeting2, or comma-joined values)
2. Columns that are empty in most rows
3. Preset values (enums) that an admin will need to add to or remove from
For each, tell me whether it should become a table or can stay a column, and why.
Do not change anything yet.