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

Question

为了学习的目的，我要开发一个个人项目。一个房地产网站，广告商(注册用户)可以为他们的房产(公寓、土地、房屋、.)发布广告。租金(在规定的期限或未确定的期限)或出售。此外，客户(访问者)可以在特定地点寻找特定类型的房产以供出租或购买。

业务规则：

• 用户是注册用户。
• 用户只有一个角色，而只有一个角色(用户、管理员、…)。
• 角色属于许多用户(每个用户的默认角色是用户)。
• 用户有一个位置，而只有一个位置(位置指地址)。
• 位置属于许多用户。
• 用户有许多属性(无论是出租还是出售)。
• 属性属于一个用户。
• 属性属于一个位置(位置指地址)。
• 文件属于属性。
• 属性有许多文件(基本上是图像)。

​

​

我做了那么多谷歌搜索，在databaseanswers.org中看到了一些数据库建模，但是我被属性的类型/特性困住了，我真的搞不懂它，我不知道最好的解决方案！因为每一种类型的房产都有不同的特征，例如公寓有房间，浴室.但是土地不是，对于那些我们可以说是进城或城外…的土地

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

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

我是否必须将每个属性的属性分离到它们自己的实体(表)，例如公寓表、土地表、房屋表…这样，我就可以用它们自己的特性来附加它们。

还是必须在一个表"Properties"中将它们与所有功能合并，并使用另一个表" Type "将每个属性链接到其类型(如Posts和类别中)。

还是必须创建四个表"Properties" "Type" 功能“”和一个支点表"feature_property".

• 财产属于一种类型(公寓、土地、房屋、…)。
• 类型有许多属性。
• 特征具有许多属性。
• 物业有许多特点。

Answer 1

还有另一种更接近关系建模逻辑根源的方法--为每个特性创建一个表，为属性id和属性创建一个列来度量或描述该特性。这样的表中的记录意味着特性应用，没有记录意味着它不适用。

至于哪种方法是最好的，这取决于。正确的方法是首先根据集合、依赖关系和约束来构建逻辑模型，然后构造实现逻辑模型的表。我建议您看一看对象角色建模，它是概念/逻辑建模的良好规则。

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

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

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

您所称的枢轴表可以很好地标记或关联事物，但不能很好地度量事物。我认为这是简单的是/否情况，如果用户可以添加或删除标记，如果我有一组固定的特性，则可能不会，如果功能有参数的话，则几乎肯定不会。

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

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