数据库中可列表集合的设计替代方案

Question

我创建了一个功能，允许将许多不同类型的东西添加到列表中。列表包含一些基本元素，如名称和说明以及所有者ID。

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

List: 
    list_id 
    list_name 
    list_description 
    list_owner_id 

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

List Items: 
list_item_id 
list_id 
rank/order 

我试图确定一些基本的东西：

我应该：

1. 做一个通用的清单表 指定的项目是 它的列表元素指向的类型，即 （列表：ELEMENT_TYPE）或

2. 作出 单独的清单表的每个类型的列表或即 （所属类别，Product_List_Items ， Comment_List，Comment_List_Items）

3. 榜上无名元素指向一个 通用的“可列表”这则 定型/指定的 事情型指向最终查找元素。 即List_Items：ELEMENT_TYPE

4. 或其他一些事情

如果我选择1，我可以从列表表中选择一个列表，然后选择联接基于知道最终的元素表加入反对做

如果让我选择2，我会永远是很好的定义静态关系，只有特定的数据在每个表

如果让我选择3，我就能各种各样的东西存放在每个列表但目前这不是要求。

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

DB design to use sub-type or not?

但不是一一对应的关系，我有一个一对多...

Answer 1

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

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

Answer 2

我通常会推荐您的选项3的设计。就像您将以OO编程语言创建一个超类（或接口），以及您的每个超类的子类“IS-A”实例。你可以在SQL中做类似的事情，但是IS-A关系是通过参照完整性来处理的。

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

我已经给出了这个答案很多次，所以通常用于问题taggegd polymorphic-associations。我在我的书SQL Antipatterns: Avoiding the Pitfalls of Database Programming中谈论它。

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