Tables, Rows, and Columns

Build the mental model

A table is a framework-neutral shape for organizing similar things: it has columns that define what pieces of information every entry has, and rows where each row is one actual entry. Picture a users table with three columns: id, name, and email.

integer — a whole number (an id)
text/string — names, emails
boolean — a true/false flag
date/time — a timestamp
decimal/numeric — values needing fractions, like prices
JSON — flexible nested data (where supported)

A row represents one instance of that thing — one user. If there are three users, the table has three rows, and each row has a value (or an explicit empty value) for every column the table defines.

Not a universal rule

'One row equals one record' is specifically how the relational, table-based shape works. Some NoSQL data models group related information differently, without a fixed columnar shape at all.

This lesson stays deliberately conceptual: it teaches you to recognize tables, rows, and columns as a shape, not the CREATE TABLE syntax. That hands-on syntax lives in this platform's dedicated SQL course.

Table: A collection of similar entries organized into rows and columns.

Column: A field that defines one attribute and its data type for every row in a table.

Row: One actual entry/record in a table, holding a value for every column.

text

THE USERS TABLE
---------------
THE USERS TABLE
-----------------
         Column      Column          Column
           |            |               |
           v            v               v
       +------+------------+------------------+
       |  id  |    name    |      email       |
       +------+------------+------------------+
Row -> |  1   |  Thida     | thida@example.com|
Row -> |  2   |  Kyaw      | kyaw@example.com |
Row -> |  3   |  Su Su     | susu@example.com |
       +------+------------+------------------+

Connect it to a real scenario

When you look at almost any list-shaped screen in an app — orders, product grids, admin user lists — you're very likely looking at exactly this table/row/column shape underneath, regardless of the database technology.

A useful habit: before designing a feature, sketch its data as a table on paper. Write the column names and fill in a couple of example rows — if you can't fill one in cleanly, the shape probably needs rethinking.

This makes the SQL course easier

Getting comfortable inferring column types by eye makes the SQL course's CREATE TABLE syntax feel like a formality later, instead of a brand-new idea.

A table has columns (defined attributes) and rows (individual records)
Each column has a data type: integer, text, boolean, date/time, decimal, or JSON
This is a conceptual shape — CREATE TABLE syntax lives in the SQL course

Try the working example

javascript

function inferType(value) {
  if (value === null) return "null";
  if (typeof value === "boolean") return "boolean";
  if (typeof value === "number") return Number.isInteger(value) ? "integer" : "decimal";
  if (typeof value === "string") {
    return /^\d{4}-\d{2}-\d{2}/.test(value) ? "date" : "text";
  }
  if (typeof value === "object") return "json";
  return "unknown";
}

function inferColumnTypes(rows) {
  const seenTypes = {};
  for (const row of rows) {
    for (const [column, value] of Object.entries(row)) {
      if (!seenTypes[column]) seenTypes[column] = new Set();
      seenTypes[column].add(inferType(value));
    }
  }
  const result = {};
  for (const [column, types] of Object.entries(seenTypes)) {
    result[column] = types.size === 1 ? [...types][0] : [...types].join(" | ");
  }
  return result;
}

const users = [
  { id: 1, name: "Thida", email: "thida@example.com", is_active: true, joined_at: "2025-01-14", rating: 4.5 },
  { id: 2, name: "Kyaw", email: "kyaw@example.com", is_active: false, joined_at: "2025-03-02", rating: 3.8 },
  { id: 3, name: "Su Su", email: "susu@example.com", is_active: true, joined_at: "2025-06-21", rating: 5 },
];

console.log(inferColumnTypes(users));

You should see

{
  id: 'integer',
  name: 'text',
  email: 'text',
  is_active: 'boolean',
  joined_at: 'date',
  rating: 'decimal | integer'
}

5-minute try-it

Run inferColumnTypes against a real array of records from your own project (an order list, a product list) and check the result.

One important caution

Assuming every data model must use fixed rows and columns — several NoSQL databases intentionally don't

Confusing a column's data type with its displayed formatting (a date column isn't 'text' just because a UI shows it as text)

Wikipedia: Table (database) — How Databases Work