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

Question

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

业务规则：

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

我做了很多谷歌搜索，在databaseanswers.org看到了一些数据库建模但是我坚持使用属性的类型/功能，我无法弄明白，我不知道最好的解决方案为了这！！因为每种类型的财产都有不同的功能，例如公寓有房间，浴室......但土地没有，对于土地，我们可以说他们在城里或外面 - 镇...

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

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

我是否必须将每个属性的类型与他们自己的实体（表格）分开，例如公寓 table， Lands 表， Houses 表...这样我可以用他们自己的功能附加它们。

或者我必须将它们合并到一个表＆＃34;属性＆＃34; 与所有功能，并有另一个表＆＃34 ;键入＆＃34; 将每个属性链接到其类型（如帖子和类别）。

或者我是否必须创建四个表＆＃34;属性＆＃34; ＆＃34;输入＆＃34; ＆＃34;功能＆＃34 34; 和数据透视表＆＃34; feature_property＆＃34; 。

• 物业属于一种类型（公寓，土地，住宅，......）。
• 类型包含多个属性。
• 功能有很多属性。
• 一个属性有很多功能。

Answer 1

另一种替代方案更接近关系建模的逻辑根源 - 为每个要素创建一个表格，其中包含属性ID列和用于度量或描述要素的属性。这样的表中的记录意味着该特征适用，没有记录意味着它不适用。

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

尽管如此，我们可以比较不同的物理方法：

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

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

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

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

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