Hacker News new | ask | show | jobs
by integraton 4621 days ago
If you make 12 schema changes in month 1 and then no schema changes for the next year, does it really make sense to keep a month's worth of data in 12 different formats and maintain code to support all of the different versions? Why not just do a simple schema change and/or data migration each time and be done with it?

And since this is supposed to aid in rapid prototyping, how does it do so? It seems to me that it does just the opposite by introducing a significant and totally unnecessary burden.

2 comments

Generally I'd only have at most 2 formats at once while you converted the older records to the new format. You're right that there's no sense in keeping around a dozen versions but there are a lot of business cases for having two versions of a schema active at once. For example, if you can't bring down your application to convert everything mid-day and instead want to do an incremental conversion.
As functional_test said. Also note that this e.g. depends on how long lived your data is.

(An update routine can be run at any point with low use like Xmas, etc. This is potentially neat, depending on use statistics.)

I'm not saying this is a common thing, but the lack of joins makes the data a bit more flexible -- this can't be too much, if nothing else because then the Javascript will begin to break.

(I do think there are much more use cases for nosql than as a Memcached with more features. Where an old job used MongoDB wasn't one.)