问题标签 [database-normalization]

在创建数据库结构时，有哪些好的指导方针或确定数据库应该规范化到何种程度的好方法？您是否应该创建一个未规范化的数据库并随着项目的进行将其拆分？您是否应该根据性能需要创建它并完全规范化并组合表？

我有一位同事正在为一个新应用程序计划一个数据库，该应用程序将有几个表，每个表都有超过 30 个字段。这过分吗？也许我只是不够进取，无法理解。

编辑：另外，很多字段都是选项类型的东西（比如在请求表上，你希望你的小部件是黄色还是绿色，他有一个带有枚举的“颜色”字段）。随着时间的推移，这些很可能会被添加或删除。我还没有真正完成数据库设计并试图自己远离它，所以也许我完全是愚蠢的，但肯定有更好的方法来做到这一点？

为什么数据库人员继续进行规范化？

它是什么？它有什么帮助？

它适用于数据库之外的任何东西吗？

规范化导致许多基本和理想的特征，包括审美愉悦。此外，它在理论上也是“正确的”。在这种情况下，非规范化被用作一种折衷方案，一种实现性能的校正。除了性能之外，还有什么原因可以使数据库非规范化？

我发现这个问题很多，我不确定最好的方法。

我的问题是如何在使用外键查找表或直接在请求它的表中使用查找表值之间做出决定，完全避免查找表关系。

要记住的几点：

• 使用第二种方法，如果在查找表中更改了数据，您将需要对引用数据的所有记录进行大规模更新。

• 这更侧重于具有大量列引用许多查找表的表。因此，每次查询表时，大量外键意味着大量连接。

• 该数据将来自从查找表中提取的下拉列表。为了在重新加载时匹配数据，值需要在现有列表中（与第一点相关）。

这里有最佳实践，还是需要考虑的关键点？

我有这些表：

CreatedByID是 的外键。Employees我有一个几乎在每次页面加载时都会运行的查询。

OfficeID只添加一个冗余列Projects来消除三个连接是不好的做法吗？或者我应该执行以下操作：

在应用程序编程中，我“先编写最佳实践，然后再优化”，但数据库管理员总是警告连接成本。

前几天我在想规范化，我突然想到，我想不出数据库中应该存在 1:1 关系的时间。

• Name:SSN? 我会把它们放在同一张桌子上。
• PersonID:AddressID? 再次，同一张桌子。

我可以想出无数个 1:many 或 many:many 的例子（带有适当的中间表），但绝不是 1:1。

我错过了一些明显的东西吗？

什么是 KISS（保持简单，愚蠢）方式来记住 Boyce-Codd 范式是什么以及如何获取非规范化表和 BCNF？

维基百科的信息：对我没有太大帮助。

我有兴趣了解像这样操作的工具：

给定一个数据库模式和一些数据，建议该模式是否可能以任何特定的规范形式结构化，然后说明如何分解该模式以产生进一步的规范化。

基本上，一个用于数据库模式设计的静态分析工具。

像其他静态分析工具一样，这样的数据库工具不需要产生完美的结果（我怀疑这样的“完美”工具在计算上是可行的），或者适用于所有数据库系统，或者免费/开源，或其他任何东西。该工具不必是独立的；它可以捆绑为一些复杂的 IDE 功能。我只是想知道外面有什么。

第一个范式表示行排序无关紧要。这是否意味着以日期作为键的一部分的表不是 1NF？例如，考虑一个股票价格表，其中日期/时间是 PK 的一部分。在这种情况下，您可以通过按日期对数据进行排序并选择前 1 行来获得最新价格。这是否意味着要实现 1NF，您需要将表拆分为：1）TickerCurrentPrice（每个股票代码 1 行）2）TickerHistoricalPrice 谢谢