Mysql 子类型和超类型 - 数据库建模

Question

我即将开发一个用于学习目的的个人项目。一个房地产网站，广告商（注册用户）可以在该网站上发布其房产（公寓、土地、房屋……）的广告，供出租（在规定期限或未规定期限内）或出售。此外，客户（访客）可以在特定位置搜索特定类型的属性以进行租或购买。

业务规则：

• 用户是注册用户。
• 用户有一个角色并且只有一个角色（用户、管理员……）。
• 角色属于多个用户（每个用户的默认角色是用户）。
• 用户有一个位置，只有一个位置（位置指地址）。
• 位置属于许多用户。
• 用户拥有许多房产（出租或出售）。
• 财产属于一位用户。
• 财产属于一个位置（位置指地址）。
• 文件属于属性。
• 属性有许多文件（基本上是图像）。

我做了很多谷歌搜索，在databaseanswers.org 中看到了一些数据库建模，但我被困在属性的类型/特征上，我无法弄清楚，我不知道最好的解决方案！因为每种类型的房产都有不同的特点，例如公寓有房间、浴室……但土地没有，对于土地我们可以说它们是在城里还是在城外——小镇……

我想将这个数据库设计得更易于维护和扩展。我不希望数据库设计结构在开发时导致更复杂的查询/代码。

如果你能给我一些关于我的“小”问题的建议，我将不胜感激。

我是否必须将每个 Property 的 Type 分开到它们自己的 Entity（表）中，例如 Apartments 表、Lands 表、Houses 表……这样我就可以将它们附上它们自己的Features。

或者我必须将它们与所有 Features 合并到一个表 “Properties” 中，并让另一个表 “Type” 来将每个属性链接到其类型（如在帖子和类别中）。

或者我必须创建四个表 “Properties” “Type” “Features” 和一个数据透视表 “feature_property "。

• 财产属于一种类型（公寓、土地、房屋……）。
• 类型有很多属性。
• 功能具有许多属性。
• 一个属性有很多特征。

Answer 1

还有另一种更接近关系建模逻辑根源的替代方法 - 为每个特征创建一个表，其中包含属性 ID 列和用于测量或描述特征的属性。此类表中有记录表示该功能适用​​，没有记录表示该功能不适用。

至于哪种方法最好，这取决于。正确的做法是先从集合、依赖和约束方面建立一个逻辑模型，然后构造表来实现逻辑模型。我建议您看一下对象角色建模，它是概念/逻辑建模的良好学科。

也就是说，我们可以比较不同的物理方法：

首先，将一堆可为空的属性组合到一个表中很简单，但空值会引入复杂性，您必须在代码和查询中处理这些复杂性，并注意属性之间隐藏的依赖关系。这对于简单的正交属性最有效，当您拥有相互依赖的属性时，最好将它们移动到子类型/特征表中。

当您需要对事物的子集实施约束时，子类型表可以很好地工作。例如，如果每间公寓都必须与不适用于土地和房屋的管理组织相关联，则可以通过子类型强制执行。

您所说的数据透视表可以很好地标记或关联事物，但不能很好地衡量事物。我会在简单的是/否的情况下考虑这个，如果用户可以添加或删除标签，如果我有一组固定的特性，可能不会，如果特性有参数，几乎肯定不会。

我上面描述的每个功能表允许您根据需要组合功能，并且可以使用 FK 约束来使某些功能依赖于其他功能。它很强大，但会产生更多的表格，这会增加开发人员的认知负担。这实际上是子类型方法的一种变体。

我在我的项目中使用了所有这些方法。请记住，即使是经验丰富的数据库开发人员在构建没有逻辑模型的表时也很容易错过异常，因此了解正常形式并牢记依赖关系非常重要。更好的是，将它们写出来并检查它们，这比修复不一致的数据要少得多。