创建数据库结构时，应遵循哪些良好准则或确定应规范化数据库多远的良好方法？您是否应该创建一个非标准化的数据库，并在项目进行时将其拆分？您是否应该对其进行完全规范化并根据性能组合表？
您要开始设计标准化的数据库，直到第3个标准格式。在开发业务逻辑层时，您可能会决定必须进行非规范化，但是never，never低于第三种形式。始终保持第一张和第二张表格的合规性。您想对代码进行标准化以简化代码，而不是为了提高性能。为此使用索引和存储过程：）
之所以没有“随便进行标准化”是因为您每次修改数据库设计时都必须修改已经编写最多的代码。
有几篇好文章：
@@ GrizzlyGuru一个聪明的人曾经告诉我，“正常化直到痛苦，非正常化直到起作用”。
它还没让我失败：）
我不同意以非规范化形式开始它，但是，根据我的经验，与规范化程度更高的数据库相比，使您的应用程序适应规范化程度较低的数据库更容易。它也可能导致其“足够好”地工作，以至于您永远无法规范化它（直到为时已晚！）
归一化意味着消除冗余数据。换句话说，未归一化或非归一化的数据库是将在多个不同位置重复相同信息的数据库。这意味着您必须编写更复杂的更新语句，以确保在各处更新相同的数据，否则您将获得不一致的数据，这反过来又意味着查询的输出不可靠。
这是一个非常大的问题，所以我会说非规范化很痛苦，而不是相反。
在某些情况下，如果您认为对数据库的特定部分进行规范化处理，如果您认为这样做的好处胜于更新数据的额外工作和数据损坏的风险，则可以。例如，在数据仓库中，出于性能原因汇总数据，并且在初次输入之后通常不更新数据，从而减少了不一致的风险。
但是总的来说，要对性能进行非规范化感到厌倦。例如，通常可以通过使用物化视图（也称为索引视图）来实现非规范化连接的性能优势，这与查询非规范化表的速度一样快，但是仍然可以保护规范化连接的一致性。数据。
Jeff在其博客中Maybe normalization isn't normal对其哲学作了很好的概述。最主要的是：不要过度标准化。但我认为，还有一个更大的要点，那就是它可能关系不大。除非您运行下一个Google，否则除非您的应用程序增长，否则您可能不会注意到很大的不同。
我认为数据库规范化是一种艺术形式。
您不希望对数据库进行过度规范化，因为您将有太多的表，这将导致即使是简单对象的查询也要花比他们更长的时间。
我遵循的一个很好的经验法则是标准化一遍又一遍重复的相同信息。
例如，如果您正在创建联系人管理应用程序，那么将地址（街道，城市，州，邮编等）作为自己的表是很有意义的。
但是，如果您只有2种类型的联系人（企业或个人），如果您知道只有2种，则需要一个联系人类型表吗？对我来说没有。
我首先要弄清楚所需的数据类型。使用建模程序来帮助Visio。您不想从非标准化数据库开始，因为您最终将进行标准化。首先，将对象放在逻辑分组中，您会看到重复的数据将这些数据放入新表中。在您觉得自己已经设计好数据库之前，我会一直保持这一过程。
让测试告诉您是否需要合并表格。编写良好的查询可以涵盖所有过度规范化的问题。
我相信，从未规范化的数据库开始，并随着进度的发展而逐渐走向规范化是最容易上手的。对于标准化多远的问题，我的理念是标准化直到开始受到伤害。听起来可能有些浮躁，但这通常是衡量距离有多远的好方法。
拥有标准化数据库将为您提供最大的灵活性和最简单的维护。我总是从规范化的数据库开始，然后仅在存在实际问题需要解决时才取消规范化。
我认为这与代码性能相似，即编写可维护的，灵活的代码，并在您知道存在性能问题时对性能进行折衷。
原始张贴者从未描述过在什么情况下将使用数据库。如果它将是任何类型的数据仓库项目，在某个时候您将需要多维数据集（OLAP）处理某些前端的数据，那么从星形架构（事实表+维度）开始而不是研究是明智的。正常化。在这种情况下，Kimball书籍将有很大帮助。
[我同意，通常最好先使用规范化的数据库，然后再进行规范化以解决非常具体的问题，但我可能会从Boyce-Codd Normal Form开始，而不是从第三范式开始。
事实是，“取决于。”它取决于许多因素，包括：
我同意您应该尽可能地规范化，并且只有在绝对必要的情况下才可以对性能进行规范化。对于实体化视图或缓存方案，通常不需要这样做。
要记住的事情是，通过对模型进行规范化，您正在向数据库提供有关如何约束数据的更多信息，从而消除了在不完全规范化的模型中可能发生的更新异常风险。
如果您进行非规范化，那么您要么必须忍受可能会出现更新异常的事实，要么需要自己在应用程序代码中实施约束验证。这剥夺了使用DBMS的许多好处，该DBMS允许您声明性地定义这些约束。
因此，假设代码质量相同，反规范化实际上可能无法提供更好的性能。
还有另一件事是，这些天硬件价格便宜，因此，解决问题通常比接受清理损坏的数据的潜在成本更具成本效益。
通常，只要您标准化了其他软件所允许的范围，就可以完成。
例如，当使用对象关系映射技术时，您将拥有丰富的语义集合，用于各种多对一和多对多关系。在幕后，将为联接表提供有效的2个主键。尽管相对罕见，但真正的规范化通常会为您提供3个或更多主键的关系。在这种情况下，我宁愿坚持使用O / R并滚动自己的代码，以避免各种数据库异常。
只需尝试使用常识。
也有人说-我必须同意他们的观点-如果您发现自己在大多数查询中将6个（幻数）表连接在一起-不包括报告相关的表-，则可以考虑对a位。