A dataset sits in a table with named typed columns, or in a rectangle addressed only by position - what do the names buy?

## Two holdings for the same numbers A **labelled table** is a rectangle whose columns are named and typed one at a time, and whose rows may or may not carry an identity of their own. A **uniform-type rectangle** - a positional rectangle - is one buffer of a single representation, addressed only by position: no field names, no row identity. The values inside the two can be identical. What differs is the metadata sitting beside them, and what that metadata makes possible. The question underneath the question is whether you know which one you are holding, and can state the ledger in both directions: what the extra metadata buys, and what it charges. ## What the names buy - **A result that is still readable five steps later.** Every operation that produces a new holding also produces names for it. The reader, the reviewer and the next step can all see which field is which without reconstructing it from the code that built it. - **Fields of different kinds side by side.** Each field carries its own representation, so timestamps, text and counts coexist in one holding. A rectangle with a single representation for every cell can only hold fields that share one. - **Addressing that survives a change of layout.** A field referred to by name still resolves after a step inserts, drops or reorders fields. An offset does not; it silently means something else. - **Something a human can check.** A field name is a claim about content. It is a weak claim, because nothing verifies it, but a weak checkable claim beats no claim at all. ## What row identity buys, where a design carries it Row identity is the per-row key a design stores beside the values. Where it exists, it is the thing that survives a reordering: filter the rows, sort them, or keep every third one, and each surviving row still answers to the same key. That is what lets two holdings be brought back together by *which record a row is* rather than by *where it sits*. This is the sentence about tables that is most often stated too broadly, so state the precondition with it: - Some designs materialise the row-label set as a first-class structure beside the values, and a lookup by label is a real operation on the holding. - Some tabular designs have **no row-identity concept at all**. Rows are addressed by position, and any identity has to be an ordinary field you carry and match on explicitly. That is a deliberate choice with its own advantages, not an omission. - Some keep row names but discourage them - a single text vector, dropped by most operations. So "you can always look a row up by its identity" is true of the first group and false of the other two. ## What positions buy The bare rectangle is not the poor relation; it is the specialised one. - Nothing has to be carried through an operation, because there is no per-field or per-row metadata to carry, and nothing has to be reconciled between two operands. - Every cell is the same kind and the same width, so a step applied to the whole holding is uniform. - Correspondence between two holdings is position alone, which is cheap - and silently wrong the moment one of them is reordered. ## The ledger, side by side | | labelled table | rectangle addressed by position | |---|---|---| | addressing a field | by name | by offset | | addressing a row | by position, and by label where the design carries one | by position | | kinds of value | one representation per field | one representation for the whole holding | | identity of a row | depends on the design | none | | metadata per operation | names carried; labels reconciled where both sides carry them | none | | what any of it enforces | nothing | nothing | ## What neither of them gives you Labels describe; they do not constrain. Naming a field does not type-check it, and carrying row labels does not make them unique - nothing in an in-process holding checks either one. This surprises people arriving from a storage engine, where a declared key is enforced by the engine itself. Here the metadata is documentation that travels with the data: genuinely valuable, and not a guarantee. ## How to answer it out loud 1. Name both holdings and what each one is made of, in one sentence each. 2. Give the ledger in both directions - names buy interpretability and mixed kinds; identity, where the design carries it, buys correspondence that survives reordering; positions buy uniformity and no metadata to keep straight. 3. Close on the limit: none of it enforces anything. A candidate who says only "a table is more convenient" has described a preference. A candidate who says what each buys, what each charges and where designs disagree has described the object.