设计数据库

Question

我目前正在尝试为我正在开发的新项目设计数据库。我的问题源于规范化和非规范化......我想弄清楚的是你应该始终将规范化到最大程度吗？数据将是用户将很少修改的信息，并且通常与数据视图报告/视图交互。

所以我的第一次尝试是对数据进行规范化，但是当我深入了解项目并意识到他们很少会添加/更改数据时，我认为从一开始就对结构进行非规范化可能会更好。

任何智慧的话......未来他们可能会比现在更多地与数据交互，但它仍然不会像订单系统或CRM系统那样。

始终欣赏输入。

- S

Answer 1

设计OLTP数据库的通常建议是normalise到3NF。

然而，DataWarehouse或OLAP数据库的最佳实践是非规范化为Fact Table和支持维度表（star schema）。

因此，这取决于您的精确使用情况。从你的描述中可以看出你有更接近OLAP的东西。

我会最初规范化所有内容然后如果存在性能问题，请查看非规范化。

如果您的报告涉及大量聚合，

SQL Server indexed views可能会对您有所帮助，您应该创建索引以尝试覆盖您的查询工作量。

• SQL Server 2008 Indexing Best Practices

• Scaling Up Your Data Warehouse with SQL Server 2008

Answer 2

标准化和适当的设计将为您节省下来的问题。即使这个特殊项目似乎不需要它，无论如何都要这样做，以确保你养成习惯，并进行练习，

由于设计不良的数据库，我不得不重写的大部分应用都存在问题。

所以，正如在这里多次说过的那样，尽可能地规范化，除非它真的伤害了性能，即便如此，只有当有一个令人信服的理由去标准化时。

Answer 3

规范化的好处：

1. 节省磁盘空间
2. 更少的冗余数据意味着更有可能拥有一致的数据
3. 在必要时更容易实现对架构和/或数据的更改

去标准化的好处

1. 更简单的SQL查询（不需要大量连接）
2. 连接很昂贵（慢），并且使用规范化的数据库，你真的应该在所有连接字段上都有索引（而不是索引是大量的工作）。

Answer 4

我总是设计到3NF（并敦促其他人）。如果您遇到特定的性能问题，那么（然后仅）可以找出恢复到非规范化数据的优点。你不仅仅为了还原而回复，因为它引入了一系列问题。

规范化数据的目的是避免数据不一致。您可以恢复性能，但通常必须引入“技巧”（如触发器）以确保数据一致性（C是ACID）。

Answer 5

第五范式（5NF）是最好的数据库设计的基础，这是你应该瞄准的目标，除非你找到特殊原因。 3NF的唯一潜在优势是它保留了5NF不具备的一些依赖性。在那些（通常很少见的）情况下，您需要决定是否值得保留依赖关系，或者是否更好地规范化并通过其他约束和业务逻辑强制执行依赖。

这个建议与数据仓库数据库一样正确。非规范化通常用作数据集市的策略，但数据仓库通常应采用普通形式。