Is a table the same as a spreadsheet sheet?

They can look similar, but a database table follows a defined schema and database-managed behavior rather than arbitrary cell layout.

Must a table contain rows?

No. An empty table can retain its columns and constraints.

Are duplicate rows impossible?

Not in SQL generally. Appropriate keys or uniqueness constraints are needed when the design requires uniqueness.

AI Glossary / Data engineering and architecture / Beginner

Table

Definition

A table is a data structure organized into rows and columns. In a relational database, its columns describe named attributes with defined types, and its rows hold records that follow that structure. A table definition can also include constraints such as keys and required values. A database table is not simply a visible grid: it is a logical object managed by the database, independent of the particular screen used to display it.

What it means

Each row should have an understandable grain: what one record represents. A customer table might have one row per customer, while an order-line table has one row per line within an order. Columns then hold facts appropriate to that grain. Deciding the grain first helps prevent repeated totals, ambiguous identifiers, and accidental mixing of entity-level and event-level information. The table's current contents are its data, while its definition describes the permitted structure.

How it works

A table is created with column names and data types, plus applicable constraints. Applications insert, query, update, and delete rows through supported interfaces. Keys can identify rows and foreign keys can express references to other tables. The database chooses storage and access methods such as pages and indexes. SQL tables may allow duplicate rows unless constraints prevent them, and they do not promise a display order without an explicit ordering request. These practical details differ from a classical mathematical relation's set semantics.

Three practical examples

Customer management: a customer table stores one current record per defined customer identifier.
Order processing: separate order and order-line tables keep order-level facts apart from item quantities and line identifiers.
AI evaluation: a result table stores one record per model version, evaluation item, and run, with enough identifiers to distinguish repeated evaluations.

Think of it this way

Think of a register with labeled columns and a clear rule for what each entry represents. The database adds types, constraints, shared access, and durable management around that register. The analogy is limited because a database table has no inherent visual layout or row order, and its physical records may be stored very differently from the grid shown on screen.

Worked example

A toy OrderLine table contains (OrderID,LineNo,ProductID,Quantity). Order O10 has line 1 for product P3 with quantity 2 and line 2 for product P8 with quantity 1. Order O11 also has line 1, for product P3 with quantity 4. LineNo alone cannot identify a row because the value 1 occurs in different orders. Under the stated rules, (OrderID,LineNo) is an appropriate composite identifier. Grouping by ProductID gives total quantities P3 = 6 and P8 = 1. If an order-level shipping charge were copied onto every line, summing that column could count one charge several times. The example connects table grain, key choice, and correct aggregation.

Illustrative case study

Fictional example: Acorn Labs stores evaluation results in a spreadsheet-like table but omits the run identifier. Repeating an evaluation produces rows that appear to conflict with the original results. The team clarifies that each row represents one item evaluated during one run of one model version, then records those identifiers. This invented case shows why a table's meaning matters as much as its column layout; it does not imply that every table needs the same key structure.

Common misconceptions and mistakes

Do not assume the first column is automatically the key or that the first displayed row is permanently first. Do not confuse a table with an index, view, or exported file, even when each appears tabular. A table can contain no rows and still have a valid definition. Also, a wide table is not automatically poorly designed, and repeated values are not automatically errors. Evaluate the dependencies and row grain rather than judging by appearance or column count alone.

Business use

Well-defined tables provide a shared foundation for operational processes, reports, and AI datasets. Their usefulness depends on consistent identifiers, appropriate types, constraints, and documented meanings. Make units, missing-value conventions, time basis, and historical behavior visible to consumers. Before joining or aggregating, confirm the grain of every participating table. A query that runs successfully can still produce misleading business results if it combines different grains or treats a copied total as an independent fact.

Check your understanding

LineNo is unique within each order but can repeat across orders. Can LineNo alone reliably identify an order-line row?

Answer: No. The identifier must include the order scope, such as (OrderID,LineNo), or use another key that genuinely identifies the same row grain.

Related terms

Learn next

choose a familiar process and define one table's grain in a single sentence. List its columns, units, and candidate keys. Add three sample rows that challenge your assumptions, including repeated local identifiers, then write one join and one aggregate and explain why their results match the intended meaning.

Sources

Sources: PostgreSQL 18, Table Basics, https://www.postgresql.org/docs/18/ddl-basics.html ; PostgreSQL 18, Constraints, https://www.postgresql.org/docs/18/ddl-constraints.html ; IBM, Tables, https://www.ibm.com/docs/en/i/7.5.0?topic=concepts-tables ; E. F. Codd, A Relational Model of Data for Large Shared Data Banks, publication record, https://research.ibm.com/publications/a-relational-model-of-data-for-large-shared-data-banks . Primary documentation excerpts and publication metadata consulted. The article distinguishes implemented SQL tables from theoretical relations; examples are original.

Previous: T-test Next: Table 2 fallacy