3 ms·
This approach doesn’t scale when business requirements change regularly such that you need to add or remove columns to an existing table. Adding new columns by
by DaiPlusPlus 6y ago
This approach doesn’t scale when business requirements change regularly such that you need to add or remove columns to an existing table.
Adding new columns by creating a new table is easy and cheap and doesn’t involve downtime. Adding 100+ columns to an existing table because the spec said a relationship went from 1:0-1 to 1:1 is a pain.
(This can be avoided with creative design with deferrable constraints, something certain major RDBMS are still lacking, gah!)
- 6nf 6y ago> Adding 100+ columns to an existing table Whaaaa 100+ columns? How often do you need to add 100 columns to an existing table? I mean honestly that has to be as rare as chicken teeth.
- no-s 6y ago>>Whaaaa 100+ columns? How often do you need to add 100 columns to an existing table? >>I mean honestly that has to be as rare as chicken teeth. Haha, and yet it happens. One of the worst databases I ever dealt with was some ridiculous variant of Universal Model for a SCADA application, the databases were named D1, D2, D3, and so on; the tables T1, T2, T3, etc; the columns C1, C2, C3, you get the picture I hope...when they hit maximum column count they would create a new table and bizarrely rebalance renumbered columns between them. In database D0 there was a catalog with all of the details relating back to the actual model. The system was actually implemented at some defense contractors and power system operators, I remember someone at Lockheed whining about hitting the number of databases limit for Sybase. Hopefully nobody has to deal with that crap any more.
- 6nf 6y agoOof I feel your pain
- kccqzy 6y agoWhoah I've never dealt with tables with more than 20 columns. Can't imagine the shops that require 100+ columns.