数据库是一种关系

Question

我的问题与数据库架构的开发有关，如下所示。

我正在开发一个购买模块，我想用它购买物品和服务。 以下是我的EER图表（请注意，服务的特殊属性很少 - 最多2个）

我的问题是将产品和服务保存在两个表中还是只保存在一个表中？

一个表格选项 - 降低复杂性，因为我只需要指定项目ID，该项目ID引用项目表，该项目表将具有“item_type”字段以标识它是产品还是服务

两个表格选项 - 是否必须在我想要引用它们的任何地方引用单独的产品或服务，并且必须在每个引用产品或服务的表中保留“item_type”字段？

目前正计划使用选项1，但想知道有关此事的专家意见。非常感谢您的时间和建议。感谢。

Answer 1

如果我要实现，我会选择Two table选项，它有点像架构规范化的第一条规则。删除多值属性。建议不要使用item_type。一旦创建了单独的表，就不需要使用item_type，只需使用外键关系即可。

考虑阅读这篇文章： http://en.wikipedia.org/wiki/Database_normalization

应该有所帮助。

Answer 2

我当然会选择“两桌”选项。您可以看到，您必须区分产品和服务，因此您可以在程序中使用switch(item_type) { ... }，也可以在产品和服务中使用完全不同的代码路径。如果需要更新数据库模式，switch更难维护。

第二个原因是NULL。我建议尽量避免使用它们 - 它们会产生比解决更多的问题。使用两个表，您可以将所有字段声明为非NULL并忘记NULL处理。使用一个表选项，您必须手动编写代码以确保如果item_type=product，那么特定于产品的字段不是NULL，而特定于服务的字段是，item_type=service，那么特定于服务字段不是NULL，而产品特定的字段是。这不是很愉快的工作，DBMS不能为你做（在SQL中没有NOT NULL IF another_field = value列约束或类似的东西。）

选择两张桌子。它更容易支持。我曾经看过一个数据库，其中所有，每一个数据只进入两个表 - 有一些页面和代码页，以确保必要的字段不是NULL。

Answer 3

实现的问题是 - SQL表中的关系已经得到了相当好的解释。这个问题有时也被称为类/子类问题。

以下是上一个答案的链接：

Relational database design multiple user types