3 ms·

> 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 s

> 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.

vbezhenar 8y ago
Why is it hard? Most of changes are atomical and either in background or instant. What change require downtime? I would argue that software change without downtime is harder and basically not solved problem for most environments unless you're using cluster of machines.
- deleted 8y ago
  [deleted]
- gnud 8y ago
  Live changes are hard because they requires precise planning, and must often be done in several steps. Imagine you're extracting some data to a new table in order to support 1:N instead of 1:1 of something. For example, introducing an address table, instead of storing the address directly in the customer table. If you can have downtime, and have a small database, this can be done with one change and one deploy - that's not very hard. If you have a big database (100s of GB), and can't have downtime, you can't grab a full table lock to rewrite all the records in one go. You'll have to do something like 1) create the new table (easy) 2) create a marker column on the old table saying 'data moved to new table', set to false on all records 3) deploy version of application that can use both schemas 4) migrate all data to the new table, flipping the marker as you go. 5) nce all records are migrated, deploy new version of application that only uses new schema 6) drop marker and old columns (there are multiple ways to do this, of course - this is one approach) Now imagine that you have 4 or 5 applications using this database. (Some reporting application, some integration with an accounting system, some integration with a marketing tool, etc). And you must do a live migration. That is _hard_.
  - vinceguidry 8y ago
    I've been wanting a 12factor-type methodological doctrine for data for a long time. Ideally, one that can fully account for how, when, and why to start introducing different kinds of databases and when you need to start exploring those options. But I'd be happy with a lexicon and fundamental strategy for managing data that allows you do relax and rely on the fundamental primitives, like 12 factor does of overall application architecture.
  - paulryanrogers 8y ago
    Queued jobs which can auto-retry will help, of they can detect incompatible changes in the data structure. Of course that'll produce some false positives in the error logs. But it's a small price to pay IMO

> 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.

vbezhenar 8y ago

Why is it hard? Most of changes are atomical and either in background or instant. What change require downtime? I would argue that software change without downtime is harder and basically not solved problem for most environments unless you're using cluster of machines.

deleted 8y ago
[deleted]
gnud 8y ago
Live changes are hard because they requires precise planning, and must often be done in several steps. Imagine you're extracting some data to a new table in order to support 1:N instead of 1:1 of something. For example, introducing an address table, instead of storing the address directly in the customer table. If you can have downtime, and have a small database, this can be done with one change and one deploy - that's not very hard. If you have a big database (100s of GB), and can't have downtime, you can't grab a full table lock to rewrite all the records in one go. You'll have to do something like 1) create the new table (easy) 2) create a marker column on the old table saying 'data moved to new table', set to false on all records 3) deploy version of application that can use both schemas 4) migrate all data to the new table, flipping the marker as you go. 5) nce all records are migrated, deploy new version of application that only uses new schema 6) drop marker and old columns (there are multiple ways to do this, of course - this is one approach) Now imagine that you have 4 or 5 applications using this database. (Some reporting application, some integration with an accounting system, some integration with a marketing tool, etc). And you must do a live migration. That is _hard_.
- vinceguidry 8y ago
  I've been wanting a 12factor-type methodological doctrine for data for a long time. Ideally, one that can fully account for how, when, and why to start introducing different kinds of databases and when you need to start exploring those options. But I'd be happy with a lexicon and fundamental strategy for managing data that allows you do relax and rely on the fundamental primitives, like 12 factor does of overall application architecture.
- paulryanrogers 8y ago
  Queued jobs which can auto-retry will help, of they can detect incompatible changes in the data structure. Of course that'll produce some false positives in the error logs. But it's a small price to pay IMO