Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Database schema changes are hard (2017)

djrobstep.com

Post reply on HN
Print view View original

31–40 of 93 posts

Re: Database schema changes are hard (2017)

#31

Post by jarnagin »

jayd16 wrote: post #10

The reason you keep a migration chain is so you have a clear path from anything in the wild to the latest. Unless I'm misunderstanding, throwing this away means you need to migrate some unknown permutation to latest. The hardest part of the migration is migrating the data and as far as I can tell that is glossed over. Why is throwing away the iterative migration version useful exactly?

Moreover, Django already has facilities for compacting migration files together: squashing.

https://docs.djangoproject.com/en/1.9/topics/migrations/#mig...

Re: Database schema changes are hard (2017)

#32

Post by bartread »

jasonkester wrote: post #26

So much of what is bad about tooling comes from this one assumption: Database schema changes are hard. If changing the schema is hard, then you come up with silly rules about when the schema can change and who can do it. You make migration tools in other languages to avoid writing the line of SQL that would change the schema. You use 3rd party tools to compare two databases and spit out change scripts automatically (…

Even if you do know SQL syntax using the tool to make the change script for you can save quite a bit of time, especially if you've made a bunch of changes which can happen if you've added new functionality.

DISCLAIMER: I worked at Redgate, who make a tool called SQL Compare that works with SQL Server, for nearly a decade. Since this article is about PostgreSQL you should check out Postgres Compare, built by my friend Neil: https://www.postgrescompare.com/. He also used to work at Redgate.

Re: Database schema changes are hard (2017)

#33

Post by Existenceblinks »

jasonkester wrote: post #26

So much of what is bad about tooling comes from this one assumption: Database schema changes are hard. If changing the schema is hard, then you come up with silly rules about when the schema can change and who can do it. You make migration tools in other languages to avoid writing the line of SQL that would change the schema. You use 3rd party tools to compare two databases and spit out change scripts automatically (…

> But that's silly. Because Database Schema Changes are Not Hard.

Live database schema changes are hard. Usually people just let server down a few seconds if schema changes and data are not huge.

Re: Database schema changes are hard (2017)

#34

Post by djrobstep »

jasonkester wrote: post #30
djrobstep wrote: post #29

Earlier quoted context omitted.

I'm not sure you read the talk, which is literally about creating SQL change scripts?

I did. Its main piece of advice is to stop writing sequential change scripts, and to instead only keep "empty", "dev", "live" schema scripts or similar, and to rely on a tool to sort out changes between them. ... which introduces all the problems that everybody here is talking about. Thus my comment above advocating not doing that.

I have no idea what document you just read, but the linked talk is literally about preparing sequential change scripts.

Re: Database schema changes are hard (2017)

#35

Post by Existenceblinks »

jayd16 wrote: post #10

The reason you keep a migration chain is so you have a clear path from anything in the wild to the latest. Unless I'm misunderstanding, throwing this away means you need to migrate some unknown permutation to latest. The hardest part of the migration is migrating the data and as far as I can tell that is glossed over. Why is throwing away the iterative migration version useful exactly?

In theory yes, but I've barely looked at those old migration files even the latest one. Barely rollback, just patch with a new one. Some people say a rollback is just another migration "up"

Re: Database schema changes are hard (2017)

#36

Post by djrobstep »

jayd16 wrote: post #21
djrobstep wrote: post #20

Earlier quoted context omitted.

What makes it more cumbersome?

If I'm understanding correctly, the suggestion is to run the migration by hand and handle issues as they arise. Not nearly as nice as an automated migration.

The talk is more about creation migration scripts than deploying them, but definitely not suggesting doing anything by hand. The idea is to ensure correctness so you can automate the deployments with confidence.

Re: Database schema changes are hard (2017)

#37

Post by chousuke »

jasonkester wrote: post #26

So much of what is bad about tooling comes from this one assumption: Database schema changes are hard. If changing the schema is hard, then you come up with silly rules about when the schema can change and who can do it. You make migration tools in other languages to avoid writing the line of SQL that would change the schema. You use 3rd party tools to compare two databases and spit out change scripts automatically (…

I don't really understand what is it about that makes RDBMS schema changes particularly harder in people's minds. All schema changes to your data can be hard or easy depending on what you do, regardless of whether that schema is implicit in the application or enforced by a database.

If the schema change is additive, it's usually easy. On the other hand, if you drop data items that older versions of applications expect, or change the semantics of existing data, you will need to proceed carefully. Whether you're using a relational database or something else doesn't really matter.

The tool you use to execute those changes doesn't really matter either if your data model changes at the whim of the developers without actual planning behind it to deal with the impact on upgrades it will have.

Re: Database schema changes are hard (2017)

#39

Post by speedplane »

chousuke wrote: post #37
jasonkester wrote: post #26

So much of what is bad about tooling comes from this one assumption: Database schema changes are hard. If changing the schema is hard, then you come up with silly rules about when the schema can change and who can do it. You make migration tools in other languages to avoid writing the line of SQL that would change the schema. You use 3rd party tools to compare two databases and spit out change scripts automatically (…

I don't really understand what is it about that makes RDBMS schema changes particularly harder in people's minds. All schema changes to your data can be hard or easy depending on what you do, regardless of whether that schema is implicit in the application or enforced by a database. If the schema change is additive, it's usually easy. On the other hand, if you drop data items that older versions of applications expec…

In an RDMS, a change in schema is hard because changing one table can affect many others. In a NOSQL database, there are far fewer connections between tables (or "objects"). There is less to wrap your head around.
Post reply on HN