Every Column Has a Type

Imagine a library drawer labeled "Dates" where someone has filed a photograph, a phone number, and one actual date. The label lied, and now nothing filed there can be trusted. Databases take this personally — so every column declares, up front, exactly what kind of fact it will accept.

The four workhorse types

A data type is a column's contract: "only this kind of fact goes in me." Different databases offer slightly different menus, but four types do most of the world's work:

• Text — names, titles, addresses. Anything made of letters (and symbols, and even digits you don't do math on).
• Number — ages, prices, counts. Facts you might add up, compare, or average.
• Date (and time) — birthdays, deadlines, "when was this created?"
• Yes/no — paid or not, active or not, returned or not. Exactly two possible values, nothing in between.

Here's the students table again, this time with each column's contract written under its label:

students
id       | name   | age      | enrolled
(number) | (text) | (number) | (yes/no)
---------+--------+----------+---------
1        | Sara   | 14       | yes
2        | Marcus | 15       | yes

Declaring types happens once, when the table is created — like ordering the drawer with the blanks pre-printed on every card.

What goes wrong without them

Types can feel like paperwork until you watch an untyped column fail. Two favorite disasters:

Sorting. Store dates as plain text and ask for them in order, and you'll get them alphabetically: "April 1" files before "January 3", because A comes before J. The drawer did what you asked — with the wrong kind of fact. Store them as real dates, and sorting means time order, always.

Math. Ask for the average of an age column where someone typed "fourteen", and the database can only shrug — you can't divide by a word. Worse is the sneaky version: digits stored as text. To a text column, "9" is bigger than "10", because character 9 files after character 1. Every one of these bugs traces back to the same root: a fact stored as the wrong kind.

A type is a promise the database then enforces. Try to file "banana" in a number column and the database refuses on the spot — politely, firmly, like a librarian handing back a photograph someone tried to file under Dates. Cheap refusal now beats mysterious nonsense later. (This idea — the database saying no at the door — gets a whole lesson in Unit 3. It's one of the best things databases do.)

Choosing well

When you design a table, choosing types forces a healthy question: what is this fact, really? A phone number looks numeric, but you'll never add two phone numbers — and some start with 0, which number columns drop. So: text. Reasoning like that is half of database design.

One column deserves special attention, though. Look at id, quietly sitting first in every grid so far, typed as a number, never explained. Next lesson it gets its moment — because it solves a problem you've already met: two students, both named Sara.