为数据库中的可列表集设计备选方案

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，Product_List_Items， Comment_List，Comment_List_Items）

3. 使列表元素指向a 通用的“可列表”元素然后 finalize /指定的类型 指向最终查找的东西。 即List_Items：element_type

4. 或其他一些东西

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

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

如果我选择3，我将能够在每个列表中存储各种内容，但目前不需要这样做。

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

DB design to use sub-type or not?

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

Answer 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的合成数据类型系统。

Answer 2

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

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