undefined | Better HN

0 pointsjiggawatts1y ago0 comments

> ALTER TABLE or CREATE TABLE

Fundamentally this isn't a theoretical limitation of the relational model, instead it is a historical artefact that "doesn't have to be that way".

Systems like Kubernetes or Azure Resource Manager show how this ought to have been implemented: Declarative resource definitions via an API with idempotency as a core paradigm.

I.e.: Instead of the web developer having to figure out the delta change between two schema versions, they should just "declare" that they want some specific schema. This could happen with every code deployment, with most such changes doing nothing. If the schema does change, then it's up to the database engine to figure out how to make it happen, much like how a Kubernetes cluster reconciles the cluster state with a deployment definition.

KV stores become popular because they do this implicitly, with no explicit schema at all.

Relational databases (or even KV stores!) could instead use an explicit schema with automatic reconciliation instead of manual delta changes implemented by developers.

TL;DR: The tooling is bad. KV is an over-reaction to this, but instead we just needed better tools.

0 comments

Izkata1y ago

Django (python web framework) migrations have worked similar to this for well over a decade: You modify the models, then generate the migrations from the models and commit those.

The changes aren't generated on the fly at runtime because it can prompt you for things it suspects or can't figure out, for example if you rename a column the naive way would be an add+delete, which erases data. If the types are the same, it checks whether you wanted that or a rename, and generates the appropriate migration.

MrLeap1y ago

> TL;DR: The tooling is bad.

I make my own tools. KV makes it really easy to stop having to care about the database layer really early in a project and live entirely in code. It's fine.

j / k navigate · click thread line to collapse