The argument for union types seems to get weak when one asks: how do we index their components?
Because there seems little middle ground between needing discrete fields and safely just parking the data as a memo field and deferring the management to the application.
Unix win by letting the system utilities specialize.
Their answer clearly, explicitly, assumes a C-style `union`. Despite the essay literally using a proper sum type as example.
> The argument for union types seems to get weak when one asks: how do we index their components?
With the system creating partial indices under the cover? I fail to see what's complicated about it.
> SQL need not be "one language to rule them all".
SQL has "won" the relational battle and is literally the only way to query relational databases. Any time SQL is unable to do the job and you have to move that job to application code, you're making the schema less reliable and less of a source of truth, because parts of the schema's information have to be embedded in each application instead.
That doesn't seem desirable to me, unless you assert SQL should just be a trivial data storage and retrieval interface, which it has not been… possibly ever, but at the very least since the introduction of window functions.
I would contend that there is a minimum set of tools across which an system will span.
However, attempts to crunch the system into One True Tool will hit the diminishing returns curve early and hard.
Quite to the contrary, many users tend toward Object-Relational Mappers, just to ease the transition between data and logic portions of the application.
The argument for union types seems to get weak when one asks: how do we index their components?
Because there seems little middle ground between needing discrete fields and safely just parking the data as a memo field and deferring the management to the application.
Unix win by letting the system utilities specialize.
SQL need not be "one language to rule them all".