Tables and Arrays

Names and per-field types make a rectangle self-describing: every field says what it is, and each field can hold a different kind of value. A rectangle addressed only by position carries one representation for everything and offsets to address it by.

A two-axis table cannot hold three coordinates directly, so it flattens one: repeat store and month down the rows beside a measure column, or fold the measure into the column labels. A holding with a third axis keeps all three.

A row label is a per-row key stored beside the values, so a row can be named rather than counted. Nothing checks it for uniqueness, duplicates are legal, and some tabular designs carry no row identity at all.

A uniform-type rectangle holds one representation for every cell, so the single text field decides it for all of them. The numeric values stop being packed numbers and are re-held in whatever form can also carry text.

The label now appears on four rows. Nothing ever checked row labels for uniqueness, so a retrieval returns however many rows carry the label asked for — and the shape of the result is decided by the data, not by the code.

One row still stands for one order, so the table's row count is the number of orders, not the number of codes. The variable-length group of codes rides inside a single cell of that row.

Column order becomes the meaning: after the conversion each field is identified only by its position in the rectangle. Any upstream change to field order or count silently re-points every downstream reader at the wrong values.

Keep the group in the cell when downstream work is addressed to the row and the group is consumed whole — counted, tested for membership, passed along. Repeat the row when the element is what you filter, match or aggregate on.

Because the holding is organised by field: a new field is one more run and reads none of the others, while a new record has to place a value into every field's storage. That direction is stable; the degree ranges from one extra chunk to a full rebuild.

Three holdings are common: one contiguous run per field; an ordered sequence of separately allocated chunks; or one slab per representation, in which a field is a slice. The logical picture is identical in all three; the costs are not.

Nothing. A field name and a row label are descriptions stored beside the values: no in-process holding compares a name with the field's contents, and none checks row labels for uniqueness. Anything the code depends on, the code must check.

Three charges: the bytes the labels occupy, the metadata every step carries through and reconciles, and a second way of naming a row that the code must keep straight. Field names are cheap; a row labelling materialised from a field is not.

Axes are named by their place in the axis-length tuple, so a reduction that removes one drops an entry and shifts every dimension after it down a place. The number that meant measures now means something else.

A full-length sequence of label values, plus whatever structure the design builds beside it to make lookup by label fast. The default consecutive labelling is usually held as a rule — a start, a step and a length — so it materialises nothing.

Expanding raises the row count to the total element count and repeats every other value in the row once per element, so per-row figures computed afterwards weight each entity by its group size. Keep the group when the work downstream is per-row.

How the table was already held decides it. Where every field shares one representation in a single contiguous slab, the conversion can hand back a window over existing bytes; otherwise it allocates a new rectangle and copies every value.

Each add is doing work proportional to the table already built, not to the new field — a shared slab rebuilt per add, or a fresh holding materialised per step. Twenty adds then cost twenty table-sized copies. Compute the fields first and attach them once.

An identity per record - either a row-label structure the design carries for you or an ordinary field you keep and match on. Position is not identity: the first filter or sort breaks correspondence between two holdings, and nothing reports it.

A dense three-axis holding allocates the product of its axis lengths — 48 million cells here — regardless of how many carry a value. At 4% density the flattened table, storing one address plus one value per real observation, is far smaller.

Selecting a span of labels is cheap only when the labels are in order, because then both endpoints can be found by bounded search. Shuffled labels remove that precondition, so the holding must examine every label instead, once per selection.

Convert late, narrow and in one declared place: at the edge of the routine that genuinely needs a positional rectangle, with an explicit ordered field list named there. Everything on either side of that seam stays named.

The physical representation differs. Packed storage keeps the child values end to end with a run of boundary offsets, so counting is arithmetic over those offsets; a reference-per-cell fallback must visit a separately allocated object for every row.

A defensible default: identity lives in an ordinary column, and is promoted into the row labels only inside a step that performs many lookups by name, then demoted before the data is handed on. Write the rule around what you require, not what one tool offers.