Every constraint in Module 8 assumed a column's data type had already been decided, CHECK (salary > 0) only makes sense because salary is a number, not text. This module steps back to that earlier decision: what a data type actually is, the five real categories every database groups its types into, and, over the next four lessons, the exact keyword each of the six databases in this course uses for each one.
Learning Objectives
- Define what a data type actually is, and the two things it controls.
- Name the five real categories every database's types fall into.
- Explain why Beacon Robotics' existing schema chose the types it did.
Column Definition
name VARCHAR(50)
Data Type
VARCHAR: variable-length text
Storage Format
How the bytes are actually kept
Valid Operations
What comparisons/math make sense
What a Data Type Actually Is
A data type is a rule attached to a column that controls two separate things: how the value is physically stored (how many bytes, in what format), and which operations are even valid on it. A NOT NULL or CHECK constraint from Module 8 controls which values of that type are allowed, a data type controls what kind of value is possible to store in the first place, before any constraint gets a chance to check anything.
This is why employees.salary is a number, not text: DECIMAL(10,2) lets the database sort it correctly (1000 after 999), do real arithmetic on it (salary * 1.1 for a raise), and reject anything that isn't actually a number. A VARCHAR column holding '1000' as text would sort it alphabetically next to '10', and salary * 1.1 would either fail outright or silently do something wrong depending on the database.
The Five Real Categories
| Category | What It Stores | Beacon Robotics Example |
|---|---|---|
| String / Text | Characters: names, codes, free text | departments.name VARCHAR(50) |
| Numeric | Whole or decimal numbers | employees.salary DECIMAL(10,2) |
| Date / Time | A calendar date, a time, or both | employees.hire_date DATE |
| Boolean | True or false | Not used yet, employees.is_manager is the example, next lessons |
| Binary | Raw bytes, not meant to be read as text | Not used anywhere in this schema |
Beacon Robotics' entire schema, built since Module 7, only actually needed three of these five: string, numeric, and date/time. That's typical, most everyday schemas never need a real Boolean or binary column. Both still get a full lesson later in this module, interview questions assume familiarity with all five, not just the ones a given project happened to use.
Try It Yourself
Classify each of these existing Beacon Robotics columns into one of the five categories: projects.name, employees.salary, employees.hire_date.
projects.name -> String / Text employees.salary -> Numeric employees.hire_date -> Date / Time
Frequently Asked Questions
Do all six databases in this course agree on these five categories?
Yes, the broad categories themselves are universal, every database groups its types into some version of string, numeric, date/time, boolean, and binary. What differs, covered over the next four lessons, is the exact keyword each database uses within a category, VARCHAR vs TEXT, DECIMAL vs NUMBER, and so on.
Why not just store every column as text and let the application sort it out?
Three real costs: storage (a number stored as text usually takes more bytes), correctness (text sorts and compares alphabetically, '100' comes before '20'), and validation (a numeric column rejects non-numeric input automatically, a text column accepts anything). The right data type does all of this for free, at the database level, for every row, forever.
Common Beginner Mistakes
Storing a number as VARCHAR because it felt simpler at the time
This quietly breaks sorting (alphabetical instead of numeric), arithmetic (no multiplying or summing a text column), and validation (nothing stops non-numeric junk from being inserted). Use the real numeric type, covered in the next lesson, even for values that look simple.
Assuming every database spells a given category's type the same way
It doesn't, PostgreSQL's TEXT, SQL Server's VARCHAR(MAX), and Oracle's CLOB are all the same category (large text) with three completely different keywords. The category is universal, the exact keyword almost never is, that's the whole reason this module exists.
Best Practices
- Choose the narrowest data type that still comfortably fits every legitimate value a column will ever need.
- Match a column's type to the real-world kind of value it represents, not to whichever type is fastest to type.
- Expect the concrete keyword to differ by database, even when the underlying category doesn't.
Interview Questions
What two things does a column's data type actually control?
How the value is physically stored (the byte format, the size), and which operations are valid on it (arithmetic, string functions, date math). A constraint like CHECK or NOT NULL is a separate, later layer, it decides which values of that already-chosen type are allowed, not what kind of value is possible in the first place.
Why might storing a phone number as INT be a mistake, even though it's all digits?
A phone number can have a leading zero or a leading +country code that INT would silently drop or reject, it's never actually used in arithmetic, and some formats include characters like a hyphen or parentheses that a numeric column can't hold at all. phone VARCHAR(20) preserves the exact digits (and formatting) as written, phone INT does not: INSERT INTO employees (phone) VALUES ('0191...') stored as INT loses the leading 0 immediately.
Summary
A data type controls how a value is stored and which operations are valid on it, a decision that comes before any constraint. Every database groups its types into the same five real categories, string, numeric, date/time, boolean, and binary, but spells the concrete keyword within each category differently, which is exactly what the next four lessons cover.
What's Next?
Numeric Data Types is next: the real difference between an exact DECIMAL and an approximate FLOAT, and why Beacon Robotics' salary column could never have safely used the latter.
Ready to Practice SQL?
Write and run real SQL queries online, right in your browser, no install or signup required. Pick a playground based on which database you want to practice on.
Both open a third-party SQL playground in a new tab. External site terms and privacy policy apply.