>If your design is good, "Draw the rest of the fucking owl" Good design is hard. There are arguments to be made for both, but the problem with "Old, Good Data

>If your design is good, "Draw the rest of the fucking owl" Good design is hard. There are arguments to be made for both, but the problem with "Old, Good Database Design" is when the design changes it either devolves into 1. Downtime trying to move X billion rows 2. Some ad-hoc K/V store on top of your RDBMS And most companies tend to opt for (2) rather than (1). It's no surprise that some systems just decide to choose (2) from the onset.