我被带到了旧学校 – 在那里我们学习了在应用程序的业务层之前设计数据库模式(或者使用OOAD来完成其他任务).我一直非常善于设计模式(恕我直言:)并规范化只是为了删除不必要的冗余,但不是它影响速度的地方,即如果连接是性能损失,冗余就留在原地.但大多数情况并非如此.
随着一些ORM框架的出现,如Ruby的ActiveRecord或ActiveJDBC(以及其他一些我不记得的,但我确信有很多)似乎他们更喜欢为每个表都有一个代理键,即使有些像主键一样’电子邮件’ – 彻底打破2NF.好吧,我理解的不是太多,但是当这些ORM(或程序员)中的一些不承认1-1或1-0 | 1(即1到0或1)时,它会让我紧张(几乎).他们规定,把所有东西都当成一张大桌子,不管它是否有大量的空白“今天的系统可以处理它”,这是我经常听到的评论.
我同意内存限制确实与规范化有直接关系(还有其他好处:)但是在今天的廉价内存和四核机器的时代,数据库规范化的概念只留给了文本？作为DBA,你仍然练习3NF的标准化(如果不是BCNF :)？有关系吗？ “脏模式”设计是否适合生产系统？如果它仍然相关,那么应该如何使案例“正常化”.
(注意：我不是在谈论数据仓库的星/雪花模式,它们具有冗余作为设计的一部分/需要,但是商业系统具有像StackExchange这样的后端数据库)
