Database Table
A table is the basic unit of storage in a relational database: a named collection of rows, each with the same set of columns, where every column has a declared name and data type that applies consistently to every row. A "customers" table might have columns for customer_id, name, email, and signup_date, and every single row in that table — every individual customer — populates those same four fields, which is the structural guarantee that makes a table queryable and aggregatable in a way an unstructured collection of records isn't.
A table's schema — the formal definition of its columns, their types, and the constraints applied to them (primary keys, foreign keys, NOT NULL requirements, uniqueness constraints) — is declared before data is inserted and enforced by the database on every subsequent write, which is the structural property that distinguishes a genuine database table from something that merely looks like one, such as a CSV file. A CSV file can have the same visual shape as a table — rows and columns, headers at the top — but nothing enforces that every row actually conforms to that shape; a database table's schema makes conformance mandatory, rejecting any insert or update that would violate it, which is why the same superficially tabular data is meaningfully more trustworthy once it's actually stored inside a properly schema'd database table rather than a flat file.
Tables connect to each other through shared key values rather than by nesting data inside a single table, which is the structural basis of the relational model: a "customers" table and an "orders" table stay separate, linked by a customer_id column that appears in both, rather than embedding every customer's full order history as a nested structure inside their own row. This separation is what normalization is built around — keeping each fact stored in exactly one table, referenced by key from anywhere else it's needed — and it's also why most meaningful queries against a relational database involve joining multiple tables back together rather than reading from a single table in isolation; a database schema is typically designed as a connected set of tables, not as one giant flat table holding everything.
A view is a saved, named query that behaves like a table for reading purposes without actually storing its own data — it recomputes its result from underlying tables every time it's queried, which makes it useful for exposing a simplified or pre-joined version of complex underlying data without duplicating storage. A materialized view takes the opposite tradeoff: it does store its computed result physically, trading the storage cost and the need for periodic refreshing against significantly faster read performance, since a materialized view doesn't have to recompute its join or aggregation logic on every single query the way a standard view does.
Table partitioning — splitting a very large table into smaller physical segments, commonly by date range or by a specific key value, while the database still presents it as a single logical table to anyone querying it — exists specifically to keep query and maintenance performance manageable as a table's row count grows into the hundreds of millions or billions, since operations like deleting old data or scanning a date range become dramatically cheaper when the physical storage is already segmented along the same lines the query is filtering on, rather than scanning the full, undivided table every time.
Read a table as the enforced, schema-bound unit that makes a relational database trustworthy in a way a plain file never automatically is: its declared schema is what guarantees every row actually conforms to the shape it claims to have, its connections to other tables through shared keys are what the entire relational model is organized around, and the supporting constructs built on top of it — views for simplified access, partitioning for scale — exist to manage the tradeoffs that come with tables holding either complex derived logic or very large amounts of data.