数据库中可列出集的设计备选方案答案

【问题标题】：Design alternatives for listable sets in a database数据库中可列出集的设计备选方案
【发布时间】：2011-03-14 18:35:42
【问题描述】：

我正在创建一个功能，允许将许多不同类型的东西添加到列表中。列表具有一些基本元素，例如名称和描述以及所有者 ID。

所以我的第一个数据模型是

 List:
  list_id
  list_name
  list_description
  list_owner_id

我的第二个数据模型看起来像：

List Items:
 list_item_id
 list_id
 rank/order

我正在尝试决定一些基本的事情：

我应该：

制作一个通用列表指定项目的类型它的列表元素指向，即（列表：element_type）或
为每种类型的列表或即（产品列表，产品列表项目， Comment_List、Comment_List_Items)
使列表元素指向通用的“可列出”元素，然后最终确定/指定的类型指向最终查找的东西。即 List_Items: element_type
或其他一些东西

如果我执行选项 1，我可以从列表中选择一个列表，然后根据知道要连接的最终元素表来选择进行连接

如果我选择 2，我将始终拥有定义明确的静态关系，每个表中只有特定数据

如果我选择3，我将能够在每个列表中存储各种东西，但这不是目前的要求。

更新：我的问题与此类似：

DB design to use sub-type or not?

但我不是一对一的关系，而是一对多的关系......

【问题讨论】：

标签： database-design

【解决方案1】：

我通常推荐您选择的设计 3。就像您将在 OO 编程语言中创建一个超类（或接口），以及您的每个子类型“IS-A”超类的实例一样。您可以在 SQL 中执行类似的操作，但 IS-A 关系是通过引用完整性处理的。

因此，您的 List_Items 表引用了 Listables，它是可以成为列表一部分的所有实体类型的父表。

我已经在 SO 上多次给出了这个答案，通常是针对问题标记为 polymorphic-associations。我在我的书SQL Antipatterns: Avoiding the Pitfalls of Database Programming 中谈到了它。

我不推荐@Gilbert Le Blanc 的解决方案described，它是Inner-Platform Effect 反模式的一种形式。 SQL 已经支持数据类型，因此您应该使用它们，而不是在 SQL 之上创建一个合成数据类型系统。

【讨论】：

【解决方案2】：

如果您的列表数量有限，那么您的选项 2 很容易理解，并且您可以为每个列表元素类型使用正确的数据库数据类型。

如果您的列表更多，那么您的选项 1 似乎是最好的选择。您将有一个 List 表和一个 List Items 表。 List Items 表中的列表元素必须是通用 VARCHAR，您还需要存储列表元素的格式（INTEGER、FLOAT、DATETIME 等），以便知道如何转换 VARCHAR成正确的格式。

【讨论】：