A table organizes data into rows and columns. Each row is a record. Each column is a field. The intersection of a row and column holds a single value. A customer table might have columns for ID, name, email, and signup date. Each row is one customer. The table is the basic unit of storage in a relational database. It is also the unit that users query. When you write SELECT * FROM customers, you are asking for every row and column in the customers table.

Tables have properties. They have a name, unique within the schema. They have columns with defined data types. They may have constraints: primary keys, foreign keys, unique constraints, check constraints. They may have indexes to speed up queries. They may have triggers that fire on insert, update, or delete. The design of the table affects everything built on it. A table with too many columns is unwieldy. A table with too few forces joins that could be avoided. A table without a primary key is hard to update reliably. A table with redundant data risks inconsistency. Normalization guides table design. The goal is to store each fact once. That reduces redundancy and improves integrity. It also increases the number of tables. More tables mean more joins. The balance between normalization and performance is a constant tension in database design.

Table components

• Columns — fields with data types
• Rows — records
• Primary key — unique identifier
• Foreign keys — links to other tables
• Indexes — speed up queries
• Constraints — rules for valid data

A table is a container for related data. The structure of the container determines how easy the data is to use.