我从小就受过教育——在那里我们学会了在应用程序的业务层之前设计数据库模式（或将 OOAD 用于其他一切）。我一直很擅长设计模式（恕我直言:) 并且规范化只是为了删除不必要的冗余，而不是影响速度的地方，即如果连接是性能下降，冗余就留在原地。但大多数情况并非如此。
随着一些 ORM 框架的出现，如 Ruby 的 ActiveRecord 或 ActiveJDBC（以及其他一些我不记得了，但我相信有很多）似乎他们更喜欢为每个表设置一个代理键，即使有些有主键，例如'email' - 彻底打破 2NF。好吧，我不太明白，但是当这些 ORM（或程序员）中的一些不承认 1-1 或 1-0|1（即 1 比 0 或 1）时，我（几乎）会感到紧张。他们规定，无论是否有大量nulls “今天的系统可以处理它”，最好将所有东西都放在一张大桌子上，这是我经常听到的评论。
我同意内存限制确实与规范化直接相关（还有其他好处:)但是在今天内存便宜和四核机器的时代，数据库规范化的概念是否只是留给文本？作为 DBA，您是否仍然练习标准化为 3NF（如果不是 BCNF :)？有关系吗？“脏模式”设计对生产系统有好处吗？如果它仍然相关，那么应该如何将其“用于”规范化。
（注意：我不是在谈论数据仓库的星形/雪花模式，它们具有冗余作为设计的一部分/需要，而是具有后端数据库（例如 StackExchange）的商业系统）