skip to content

What does a column declared to hold one of a small named set of kinds give you that a hold-anything column does not?

level: middleimportance: should knowfreq 42%

answer

  1. one is silent, the other declares
  2. closed set of kinds
  3. a tag per row you can trust
  4. the branch moves to every reader

basics

~20 s

A closed, named set of kinds and a per-row tag. Consumers can branch over every case that exists, and an unexpected fourth kind is refused rather than absorbed, where a hold-anything column accepts everything and records nothing about what arrived.

solid answer

~50 s

Both representations admit that the column carries more than one kind of thing; they differ in whether that fact is **written down**. A declared union states the permitted kinds up front and tags each row with which one it holds. Three things follow. The set is **closed**, so a kind nobody planned for is rejected at the boundary instead of quietly joining the column. Each row is **self-describing**, so a reader branches on a tag it can trust rather than inspecting the value to guess. And storage can stay disciplined — each kind's values can still live in a packed buffer with a small tag beside them — instead of collapsing to one reference per row. The price is that every consumer now has to handle every branch, and that fewer designs offer this at all, so it is often not on the menu.

go deeper

for a junior

Recall the difference in one line: a hold-anything column accepts everything and says nothing, while a declared union lists the kinds allowed and labels each row.

for a middle

Explain the two mechanics — a closed set stated in advance and a per-row tag — and be able to say what each one prevents that the permissive form does not.

for a senior

Show judgment about when the mixture belongs to the domain and when it is damage, and say what a union commits every downstream reader to before you propose one.

for a principal

Weigh a declared union as an interface decision: it buys the platform an enforceable boundary and charges every consuming team a branch, which is worth it only when the kinds are stable enough to be worth naming.

## Two ways to admit a column is not uniform Once a column genuinely carries two kinds of thing, there are two honest ways to store it, and they differ in how much they tell the next reader. The **holder-for-anything representation** stores one reference per row and lets each row be whatever it is. It is permissive and it is silent: nothing in the column says what kinds are present, how many of each, or whether a new one appeared this morning. Every consumer discovers the answer by inspecting values, one at a time. A **declared union column** is allowed to hold a value from a **small named set of kinds**, and every row carries a tag saying which. The set is stated when the column is defined, not discovered from the data. ## What the declaration buys | | hold-anything | declared union | |---|---|---| | kinds present | discovered by inspection | stated up front | | an unplanned kind | absorbed silently | refused at the boundary | | per-row knowledge | none until you look | a tag you can trust | | storage | one reference per row | per-kind values plus a small tag | | consumer code | must cope with anything | must handle each named case | The most valuable line is the second. A hold-anything column has no notion of an unexpected value, because nothing is unexpected — that is its entire semantics. A declared union does, and that is what turns a silent contamination into a failure at the place it entered. The third line is what makes downstream code honest. Branching on a tag is a decision the reader can enumerate and a reviewer can check for completeness. Branching on the result of inspecting a value is a guess that happens to be right on today's data. ## What it costs - **Every read site branches.** A union does not remove the problem, it relocates it from "whoever eventually trips over it" to "everyone who reads the column". That is usually the right trade, but it is not free, and on a column read in fifty places it is fifty branches. - **Someone must still decide what each kind means.** Tagging a row as text rather than a quantity does not say whether it should be excluded from a total, mapped to something, or reported. The union makes the decision visible and unavoidable; it does not make it for you. - **Not every design offers one.** Across the tools in this space, support ranges from a first-class union with per-row tags, through conventions that fake it with a kind column beside a value column, to no such concept at all. Where it is absent, the real choice is between refusing the value and falling back — so check before you design around it. - **It is a poor fit for genuinely open data.** If the kinds are not a small, stable, named set, a union is an inventory you will be editing constantly, and the permissive representation is the honest one. ## When it is the right answer A union earns its keep when the mixture is **expected and bounded**: a measurement that is either a number or one of three documented non-answers; an identifier that is either numeric or a short alphabetic key from an older system. In those cases the mixture is part of the domain, and forcing it into one representation either destroys information or requires a convention everyone has to remember. It is the wrong answer when the mixture is **an accident**. If a quantity column has text in it because something upstream went wrong, declaring a union blesses the defect and asks every consumer downstream to keep coping with it forever. Refusal is the better instrument there, because it keeps the cost where the fix is. ## What a strong answer sounds like A candidate worth hiring names the two mechanical differences — the closed set and the per-row tag — and then makes the tradeoff explicit in one sentence: a union moves work from an unknown future reader to every present reader, in exchange for never again being surprised by a kind nobody wrote down. They also say that this option is not universally available, rather than assuming everyone's tools look like the one they know, and they distinguish a mixture that belongs to the domain from a mixture that is damage.

  • If a union still lets the column hold two kinds, what has actually improved?
    Knowledge and closure. Every row says what it is, so readers branch instead of inspecting, and the set of kinds is fixed in advance, so a third kind is rejected where it enters rather than joining the column unannounced. The mixture is the same; the surprise is gone.
  • When would you prefer refusing the value over declaring a union?
    When the mixture is damage rather than domain. If text appears in a quantity column because something upstream broke, a union makes every future consumer carry that breakage forever. Refusal keeps the cost next to the fix. Declare a union only when the extra kinds are expected, bounded and meaningful.
  • What is a workable substitute where the tools have no union concept?
    A pair of columns: one typed column holding the values of the dominant kind, with rows of other kinds left absent, and a second small column recording each row's kind. It is the same information laid out by hand, keeps the typed pass over the dominant kind, and stays inspectable — at the cost of a convention every reader must know.

saying these in an interview costs you the question

  • Thinks a union and a hold-anything column are the same thing
  • Assumes every tool in this space offers a union type
  • Says a union removes downstream work rather than relocating it
  • Reaches for a union when the mixture is upstream damage
  • Believes tagging a row also decides what to do with it