database - 关于数据库建模的问题

Question

您将如何在数据库中对这些关系建模？

您有一个可以包含 PageElements 的 Page 实体。

PageElement 可以是文章或图片。文章表显然比图片有其他成员/列。一篇文章可能有。 “Title”、“Lead”、“Body”列都是 nvarchar 类型，而 Picture 可能有类似“AltText”、“Path”、“Width”、“Height”的内容。我喜欢它是可扩展的，谁知道 3 个月后我可能需要什么 PageElements？所以我想我需要一个 PageElementTypes 表。

对于关系，像这样的表呢:

Pages 带有 Id 和其他乱七八糟的东西。 (创建日期，可见，等等)

Pages_PageElements 带有 PageId 和 PageElementId。

PageElements 带有一个 Id 和一个 PageElementTypeId 以及更多胡言乱语(SortOrder、Visibility 等)。

PageElementTypes 具有 ID 和名称(例如“文章”、“图片”、“地址 block ”)

现在，我是否应该在每个 Articles、Pictures、AddressBlocks 表中创建一个 PageElementId 列来完成这一切？这就是我有点卡住的地方，这是一个简单的 1:1 关系，所以这应该有效，但不知何故我可能会错过一些东西。

跟进:

下面推荐的具有单独属性的解决方案是否会强制我将所有属性存储为同一类型？如果一个 PageElement 的属性是 nvarchar(255) 而有些是 nvarchar(1000)，如果有些是整数怎么办？

如果我采用 EAV 方式，我将不得不创建大量表来保存所有不同数据类型的属性值。

Answer 1

两个常见的选择是Single Table Inheritance和 Multi Table Inheritance .其他方法包括 tables for each concrete class我从未使用过，我称之为元表实现，其中属性定义被移动到数据而不是任何类型的模式中。

我对 STI 有过很好的体验。 ，并且只要您不期望有过多的类和属性，它就是最简单的解决方案。在我看来，简单非常好。

除非用户需要在运行时创建新的页面元素类型，否则我会避免使用元表方法和任何看起来像它的方法。根据我的经验，与开发人员定期更新的更具体的实现相比，这样的代码很快就会变成一个泥潭，而且很少能提供多少值(value)。