Database Schema Changes
The cluster focuses on challenges with ALTER TABLE operations, such as adding/dropping columns, changing types, downtime, locks, and workarounds like live migrations, transactional changes in PostgreSQL vs. MySQL, and schemaless alternatives.
Activity Over Time
Top Contributors
Keywords
Sample Comments
Why is it hard to drop an extra column from a database, or to change its type? ALTER TABLE...
Yeah, its a pity it doesn't have the ability to do anything more than alter table statements that add to a schema, having to rename the table, create a new schema and copy its contents from the old table can be quite a tricky and troublesome thing to do if you've got a live system running with users on it.
Database 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 b
Or using a more appropriate RDBMS that allows for online and transactional ALTER commands?
"Do not perform table alter commands. Table alter commands introduce locks and downtimes. Instead, use live migrations."You know what avoids alter? Going schemaless.
Please don't use databases that don't support transactional schema changes. You will hate everything about it.
Unfortunately, we're still in that time. I don't see "ALTER TABLE" go away any time soon :)
The "missing alter table" problem affects more or less any kind of schema-free DB.
Note: no `ALTER TABLE` in their SQL.Sounds like maintaining this over longer term with evolving data would be quite painful.
That's right up there with changing the purpose of a column in a SQL table, after a certain date.