9 ms·
My only exposure to NoSQL in production is using document oriented databases for data that, if put in an SQL database, would require schema alterations over tim
by sbov 16y ago
My only exposure to NoSQL in production is using document oriented databases for data that, if put in an SQL database, would require schema alterations over time.
This might fall under scalability, but I've worked on a few projects where we just continually added new tables because applying an alter on the existing table in production would take an unknown amount of time. Another thing we sometimes did would be to have 2 active tables and migrate the data over a few weeks while applying updates to both tables. Both options kinda suck. Its generally not an issue if you only have a little data though, so hence "might fall under scalability."
- saurik 16y agoDatabase servers like PostgreSQL can do the most common updates (add, delete, rename columns) instantly, S they Re abstracting over the underlying data storage. Only changing the type of a column should require reading and writing it, and you can do that change using a new temporary column and renaming it around, rather than using a whole new table. Even the alterations that take time can often be run with MVCC semantics, so existing users won't block. I don't even think MySQL (which is really bad at this) is as bad as the reality you are describing.
- sbov 16y agoIt must be a MySQL thing then. At least when using InnoDB, it doesn't do column adds or deletes instantly. If your table is large enough it can take hours - we have several where this is the case. During this time writes to the table are blocked.
- saurik 16y ago(I was on an iPhone, btw, and accidentally hit the shift key instead of "a" a couple times, causing the "S they Re".)