如何在数据库中对这些关系进行建模？
您有一个可以包含 PageElements 的页面实体。
PageElement 可以是文章或图片。文章表显然除了图片之外还有其他成员/列。一篇文章可以有 ie。 “Title”、“Lead”、“Body”列均为 nvarchar 类型，而图片可能具有“AltText”、“Path”、“Width”、“Height”等内容。我喜欢它是可扩展的，谁知道 3 个月后我可能需要什么 PageElements？所以我想我需要一个 PageElementTypes 表。
对于关系，像这样的表怎么样:
页面，带有 Id 和其他胡言乱语。 (创建日期，可见，等等)
Pages_PageElements 以及 PageId 和 PageElementId。
PageElements，带有 Id 和 PageElementTypeId 以及更多内容(排序顺序、可见性等)。
PageElementTypes 带有 Id 和名称(例如“Article”、“Picture”、“AddressBlock”)
现在，我应该在每个文章、图片、AddressBlocks 表中创建一个 PageElementId 列来完成任务吗？这就是我有点卡住的地方，这是一个简单的 1:1 关系，所以这应该可行，但不知何故我可能会错过一些东西。
跟进:
下面推荐的具有单独属性的解决方案会迫使我将所有属性存储为同一类型，或者不是？如果一个 PageElement 的属性为 nvarchar(255)，有些属性为 nvarchar(1000)，如果有些属性为整数怎么办？
如果我采用 EAV 方式，我将必须创建大量表来保存所有不同数据类型的属性值。
最佳答案
两个常见的选择是 Single Table Inheritance和 Multi Table Inheritance 。其他方法包括 tables for each concrete class我从未使用过它，我称之为元表实现，其中属性定义被移入数据而不是任何类型的模式中。
我在 STI 方面获得了总体良好的体验，并且只要您不期望有过多的类和属性，它就是最简单的解决方案。在我的书中，简单是非常好的。
除非用户需要在运行时创建新的页面元素类型，否则我会避免使用元表方法和任何看起来像它的方法。根据我的经验，与开发人员定期更新的更具体的实现相比，此类代码很快就会陷入泥潭，并且很少能提供太多值(value)。
关于database - 关于数据库建模的问题，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/333431/