pay*_*ing 25 database-design database-recommendation
我正在设计一个数据库，我正在重新考虑我最初的设计决定......
产品类型如下... 型号、零件、替换零件套件和选项。
选项 A（第一个设计）：我计划为上述产品类型设置单独的表格。我想说每个表中大约 75% 的字段是相同的。
我将每个产品类型创建为单独的表，因为我需要在它们之间创建关联。例如，一个模型可以有很多选项，一个选项可以有很多模型。一个选项也可以有很多部分，一个部分可以有很多选项……等等……
选项 B：我可以创建一个名为 Product 的表格，而不是单独的表格，其中包含模型、零件、替换零件套件和选项。我可以有一个称为 type 的字段来区分模型、选项等。我认为不利的一面是某些产品类型永远不会使用几个字段（留空）。我猜这就是“非最佳实践”发挥作用的地方。
选项 B 将大大降低数据库设计的复杂性。在提取数据进行查询时，我也不必担心引用一堆表......
如果这是我的设计决定，我可能会选择更多的“选项 C”（修改后的选项 a）。
一方面，我喜欢每个产品都有自己的桌子提供的清晰度。如果都是一张大表，有一个字段来确定类型，那么关系就不那么清楚了。
另一方面，索引策略将始终要求列出该类型字段。由于只有4种类型，所以索引基数极低（SELECT * FROM product_table WHERE type='X'反正基本上都是做全表扫描的）
缺点是确保在更新/删除事物时避免孤立以及最初设计使用这些表的查询的复杂性。
我建议您从“正确”的关系模型开始，您的选项 A。如果该模型的典型用法导致您在某些领域进行非规范化，请不要害怕这样做。
上周我和一位同事讨论了模式设计如何通常被认为是一成不变的东西，永远不会改变。奇怪的是，考虑到重构在应用程序的每个其他层中是如何被接受的实践，重构数据库模式仍然被认为是不切实际的。
如果数据库接口设计得很好，那么当您了解更多关于系统使用模式的信息时，没有什么可以阻止您调整模式。