4 ms·
This fills a gap for me. I tend to think of a database schema in declarative terms ("table T has these fields"), whereas the SQL DDL statements are more akin t
by muxator 9y ago
This fills a gap for me.
I tend to think of a database schema in declarative terms ("table T has these fields"), whereas the SQL DDL statements are more akin to commands (ALTER table T, adding a column). This always felt bad to me, because in order to define the final state of your schema, you need to define the initial state plus the commands necessary to get to the new one.
A diff tool frees you from this pain.
- evanelias 9y agoIndeed, although you can take it a step further than just diff'ing. Following the philosophy of infrastructure-as-code, a fully declarative approach would be a repository of schema files, and tooling that can convert changes to the repo to actual DDL, which it then knows how to execute safely (even taking into account multiple dev/stage/prod environments, sharding, etc). I built a tool called Skeema that does this, although it only supports MySQL / MariaDB / Percona Server for now. https://github.com/skeema/skeema/ https://github.com/skeema/skeema/ It's currently a stateless CLI tool, using git-like semantics: you can pull from a db to the filesystem, or push from the filesystem to a db / environment, or diff to preview what DDL would be generated. But the next iteration may include integration with CI/CD workflows, Github API, etc for a more seamless workflow. e.g. if you want to add a column to a table, create a pull request modifying the file, and the tooling automatically applies the DDL to a staging environment. Then get your PR reviewed/approved, and once you merge to master the tooling automatically applies the DDL to production.