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

Question

我即将开发一个用于学习目的的个人项目。一个房地产网站，广告客户（注册用户）可以为他们的房产（公寓，土地，房屋...）出租广告（定义期限或未定义期限）或出售广告。此外，凡客户（游客）可以搜索的特定类型的房产或购买在特定的位置。

业务规则：

• 用户是注册一个。
• 用户有一个角色，只有一个角色（用户，管理员...）。
• 角色属于许多用户（每个用户的默认角色是用户）。
• 用户有一个位置，只有一个位置（位置指地址）。
• 位置属于许多用户。
• 用户有很多属性（无论是出租还是出售）。
• 属性属于一个用户。
• 属性属于一个位置（位置指地址）。
• 文件属于属性。
• 属性有很多文件（基本上是图片）。

我做了这么多的谷歌搜索，看到了一些数据库建模databaseanswers.org但我卡在属性的类型/功能，我真的不能弄清楚，我不知道最好的解决方案！因为每种类型的酒店有不同的功能，例如公寓有客房，浴室......但土地没有，对土地，我们可以说他们是在城镇或出城......

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

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

我必须每个物业的例如公寓表，土地表，房子分出类型自己实体（表）表......这样，我可以将它们用自己的功能。

还是我必须合并它们在一个表“属性”所有的特点，并有另一个表“类型”每个物业到其类型的链接（如在帖子和类别）。

还是我必须创建四个表“属性”“类型”“功能”和数据透视表“feature_property”。

• 房产属于一种类型（公寓，土地，房屋，...）。
• 类型有许多属性。
• 功能有很多属性。
• 属性有许多功能。

Answer 1

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

至于哪种方法最好，取决于。做到这一点的正确方法是首先根据集合，依赖关系和约束建立逻辑模型，然后构建表来实现逻辑模型。我建议你看看对象角色建模，这是一个概念/逻辑建模的良好学科。

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

首先，一帮可空的属性组合成一个单一的表是很简单，但空介绍，你必须在你的代码来处理的复杂性和查询并注意属性之间的隐藏依赖关系。这适用于简单的正交属性，当你获得相互依赖的属性时，将它们移动到子类型/功能表可能会更好。

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

你称之为数据透视表的工作很好地标记或关联的东西，但不太好以衡量事情。我认为这是简单的是/否情况，如果标签可以被用户添加或删除，可能不是如果我有一组固定的功能，几乎肯定不是如果功能有参数。

上面介绍的每个功能表允许您按需要组合功能，并且可以使用FK约束使某些功能取决于其他功能。它功能强大，但可能会产生更多表格，从而增加开发人员的认知负担。这实际上是子类型方法的变体。

我在我的项目中使用了所有这些方法。请记住，即使有经验的数据库开发人员也可以在没有逻辑模型的情况下构建表时轻松地忽略异常情况，因此了解常规表单并牢记依赖关系非常重要。更好的是，将它们写出来并检查它们，它比需要修复不一致数据的成本要低很多。