3 ms·
If you're leaning on migrations often, with SQL, then I think you should not be using SQL, obviously (or you're just doing something wrong) Or, one should use a
by tinix 9y ago
If you're leaning on migrations often, with SQL, then I think you should not be using SQL, obviously (or you're just doing something wrong) Or, one should use a SQL database that allows more abstract data types (like JSON blobs in Postgres)
- afarrell 9y agoSo where is your data model enforced if not in your tables?
- tinix 9y ago> So where is your data model enforced if not in your tables? It's enforced... ...in the models. :P
- jnbiche 9y agoAnd how do you keep your database schema under version control? Edit: Do all you downvoters not keep track of your schema changes as you develop your application (via migrations, or even sql files), so you can easily roll back changes if needed?
- tinix 9y agoThe models live in version control. It's that simple. If your data structure is changing so often in such a way that you need to keep a history, then I'm afraid you have some fundamental problems that no amount of tooling or process can solve. You will not be able to scale your development efforts with this type of constantly changing data model, even with a migration library. If these are truly problems that you or your team has, then you should hire someone to help you organize your application, data, and workflow in a more effective manner.
- gjjrfcbugxbhf 9y agoI prefer to make use of the strong type system and inbuilt integrity checks that a database gives. json blobs mean reimplimenting this at app level. The people paying me are paying me to build their products not reinvent the wheel. Migrations are an excellent tool if you aren't using them you are doing something wrong.+ Edit + assuming that you are working with a relational database and have an agileish development process or ever have requirements changes.