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

前端之家收集整理的这篇文章主要介绍了数据库设计 – 数据库规范化是否已经死亡?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我被带到了旧学校 – 在那里我们学习了在应用程序的业务层之前设计数据库模式(或者使用OOAD来完成其他任务).我一直非常善于设计模式(恕我直言:)并规范化只是为了删除不必要的冗余,但不是它影响速度的地方,即如果连接是性能损失,冗余就留在原地.但大多数情况并非如此.

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

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

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

解决方法

规范化的一个原因是删除数据修改异常
ORM通常不支持这一点.

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

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

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

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

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

原文链接:https://www.f2er.com/mssql/80402.html

猜你在找的MsSQL相关文章