数据库中可列出集的设计替代方案
我正在创建一个功能，允许将许多不同类型的事物添加到列表中。列表包含一些基本元素，例如名称、描述和所有者 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，我将能够在每个列表中存储各种内容，但这不是目前的要求。
更新：我的问题与此类似：
但我不是一对一的关系，而是一对多的关系......
I'm creating a feature to allow lots of different types of things to be added to lists. A list has some basic elements like a name and description and owner id.
So my first data model is
List:
list_id
list_name
list_description
list_owner_id
And my second data model looks something like:
List Items:
list_item_id
list_id
rank/order
I'm trying to decide some basic things:
should I:
make a generic list table that
specifies the types of items that
it's list elements point at, i.e.
(List: element_type) ormake separate list tables for
each type of list or i.e.
(Product_List, Product_List_Items ,
Comment_List, Comment_List_Items)make the list elements point at a
generic "listable" element that then
finalizes/specifies the type of the
thing pointed at for final lookup.
i.e List_Items: element_type- or some other thing
If I do option 1, I can select a list from the list table, then choose to do joins based on knowing the final element table to join against
If I choose 2, I will always have static relationships that are well defined, with only specific data in each table
If I choose 3, I will be able to store a variety of things in each list, but this is not a requirement at this time.
Update: my question is similar to this:
DB design to use sub-type or not?
but instead of a one to one relationship I have a one to many...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我通常推荐您选择 3 的设计。就像您在 OO 编程语言中创建一个超类（或接口），以及该超类的每个子类型“IS-A”实例一样。您可以在 SQL 中执行类似的操作，但 IS-A 关系是通过引用完整性处理的。
因此，您的 List_Items 表引用 Listables，它是可以成为列表一部分的所有实体类型的父表。
我已经多次给出这个答案，通常是针对 taggegd polymorphic-associations。我在我的书 SQL 反模式卷 1：避免陷阱数据库编程。
我不推荐描述的解决方案作者：@Gilbert Le Blanc，这是内部平台效应反模式的一种形式。 SQL 已经支持数据类型，因此您应该使用它们，而不是在 SQL 之上创建一个综合数据类型系统。
I usually recommend the design that is your option 3. Just like you would create a superclass (or interface) in an OO programming language, and each of your subtypes "IS-A" instance of the superclass. You can do something similar in SQL, but the IS-A relationship is handled through referential integrity.
So your List_Items table references Listables, which is a parent table for all the types of entities that can become part of a list.
I've given this answer numerous times on SO, usually for questions taggegd polymorphic-associations. And I talk about it in my book SQL Antipatterns Volume 1: Avoiding the Pitfalls of Database Programming.
I don't recommend the solution described by @Gilbert Le Blanc, which is a form of the Inner-Platform Effect antipattern. SQL already supports data types, so you should use them instead of creating a synthetic data-typing system layered on top of SQL.
如果您的列表数量有限，那么选项 2 很容易理解，并且您可以为每个列表元素类型使用正确的数据库数据类型。
如果您的列表较多，那么选项 1 似乎是最佳选择。您将有一个列表表和一个列表项表。 List Items 表中的列表元素必须是通用 VARCHAR，您还需要存储列表元素的格式（INTEGER、FLOAT、DATETIME 等），以便知道如何转换 VARCHAR转换为正确的格式。
If you're going to have a limited number of lists, then your option 2 is easy to understand, and you can use the correct database data types for each of the list element types.
If your lists are more numerous, then your option 1 seems like the best bet. You'd have a List table and a List Items table. Your list element in the List Items table would have to be a generic VARCHAR, You'd also want to store the format of the list element (INTEGER, FLOAT, DATETIME, etc.) so that you'd know how to convert the VARCHAR into the correct format.