4 ms·

Maybe I'm thinking of this wrong, but this is one of the strong suites of NoSQL IMO. Especially when you're starting to build a new service, where you're not su

Maybe I'm thinking of this wrong, but this is one of the strong suites of NoSQL IMO. Especially when you're starting to build a new service, where you're not sure what exactly your data structure is until the whole system comes together, it's really easy to iterate and add new columns, change existing ones, etc. As long as your code treats each item as its own entity (rather than a row in a predefined table), you can continue to try new formats until you eventually lock in something that does everything you need. SQL is much less forgiving. Database migrations are terrifying, but the longer you put it off the longer migrating will take (since new rows will continue to accumulate). Perhaps the solution is "plan out your data structures ahead of time", but given that we're human, I think it's really difficult to do so correctly on the first try. For example, you may have an int column to keep track of the number of "Likes" an item on your service gets, but it may not be until later that you realize you also need to keep track of who liked what in order to prevent users from liking something twice. This is an elementary example, but the point is that when you design tables, especially if you design them around the frontend, you end up leaving out some critical columns that the backend needs to implement its features. Whenever you end up discovering this, you have to not only add that column to a new table but also retroactively insert every existing row into the new table. At best this is O(n) but if you're using a database there's a good chance your n will be quite larger. You could argue that maybe in the startup stage your n will still be small, since you won't have a billion users off the bat, but I would counter that you usually don't realize what you need to change until someone else breaks something (assuming you have tests for your code already) or requests something new, at which point you likely have an established user pool.

sipos 8y ago
Database migrations are not hard when you have hardly any data, when you are still building something, and they aren't that hard unless you have enormous amounts. On the other hand, having data where records have different attributes is annoying to have to handle everywhere at runtime, especially if it is because of something you have changed, and no new records are missing it. You just end up with code littered with handling of differences due to old design. This is, IMHO, not a good reason to use NoSQL.
kd5bjo 8y ago
When you want to change how your data is stored you have two options: 1) Don't touch the old data, and make sure all your code knows how to handle both the new and old layouts 2) Update the old data to comply with the new layout #1 is cheaper in the moment, but makes your software more fragile because of the special cases: you now have two codepaths to check for every change instead of one. Also, whatever improvements the new layout is supposed to provide aren't available to the old records. #2 is more expensive right now, and scarier because your migration will be touching everything at once. If it starts trashing data, it'll trash all of it before you have a chance to stop it. On the other hand, after you've successfully migrated, all your data is consistent and you don't need to forever deal with legacy records in the active codebase. Both approaches can be used with either SQL or NoSQL datastores, and there's no reason you have to pick the same strategy for every schema change. There's pros and cons to both approaches and which one is better will depend on your particular situation.

sipos 8y ago

Database migrations are not hard when you have hardly any data, when you are still building something, and they aren't that hard unless you have enormous amounts. On the other hand, having data where records have different attributes is annoying to have to handle everywhere at runtime, especially if it is because of something you have changed, and no new records are missing it. You just end up with code littered with handling of differences due to old design. This is, IMHO, not a good reason to use NoSQL.

kd5bjo 8y ago

When you want to change how your data is stored you have two options: 1) Don't touch the old data, and make sure all your code knows how to handle both the new and old layouts 2) Update the old data to comply with the new layout #1 is cheaper in the moment, but makes your software more fragile because of the special cases: you now have two codepaths to check for every change instead of one. Also, whatever improvements the new layout is supposed to provide aren't available to the old records. #2 is more expensive right now, and scarier because your migration will be touching everything at once. If it starts trashing data, it'll trash all of it before you have a chance to stop it. On the other hand, after you've successfully migrated, all your data is consistent and you don't need to forever deal with legacy records in the active codebase. Both approaches can be used with either SQL or NoSQL datastores, and there's no reason you have to pick the same strategy for every schema change. There's pros and cons to both approaches and which one is better will depend on your particular situation.