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

Posted 2023-03-24

【中文标题】数据库中可列出集的设计备选方案

【英文标题】：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?

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

【参考方案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成正确的格式。