数据库设计 – 数据库规范化是否已经死亡？

我被带到了旧学校 – 在那里我们学习了在应用程序的业务层之前设计数据库模式(或者使用OOAD来完成其他任务).我一直非常善于设计模式(恕我直言:)并规范化只是为了删除不必要的冗余,但不是它影响速度的地方,即如果连接是性能损失,冗余就留在原地.但大多数情况并非如此.

随着一些ORM框架的出现,如Ruby的ActiveRecord或ActiveJDBC(以及其他一些我不记得的,但我确信有很多)似乎他们更喜欢为每个表都有一个代理键,即使有些像主键一样’电子邮件’ – 彻底打破2NF.好吧,我理解的不是太多,但是当这些ORM(或程序员)中的一些不承认1-1或1-0 | 1(即1到0或1)时,它会让我紧张(几乎).他们规定,把所有东西都当成一张大桌子,不管它是否有大量的空白“今天的系统可以处理它”,这是我经常听到的评论.

我同意内存限制确实与规范化有直接关系(还有其他好处:)但是在今天的廉价内存和四核机器的时代,数据库规范化的概念只留给了文本？作为DBA,你仍然练习3NF的标准化(如果不是BCNF :)？有关系吗？ “脏模式”设计是否适合生产系统？如果它仍然相关,那么应该如何使案例“正常化”.

(注意：我不是在谈论数据仓库的星/雪花模式,它们具有冗余作为设计的一部分/需要,但是商业系统具有像StackExchange这样的后端数据库)

解决方法

我有许多Hibernate设计的数据库的例子,它们打破了这个原则：

>膨胀(字符串重复超过100万行)
>没有查找表(见上文)
>没有DRI(约束,键)
> varchar聚簇索引
>不必要的链接表(例如,当可以为空的FK列就足够时强制执行1..0：1)

我见过的最糟糕的是一个1TB的MySQL数据库,因为这些数据库可能要大75-80％

我还建议大多数米老鼠系统的声明“今天的系统可以处理它”.随着你的扩展,今天的系统不会.

在上面的例子中,重构或更改密钥或修复数据没有任何牵引力：只是抱怨数据库增长率和无法在其上构建有意义的DW

（编辑：东莞站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!