0

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

商业规则:

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

在此处输入图像描述

我做了很多谷歌搜索,在 databaseanswers.org 中看到了一些数据库建模,我被困在属性的类型/功能上,我无法弄清楚,我不知道最好的解决方案!因为每种类型的房产都有不同的特点,例如公寓有房间、浴室......但土地没有,因为土地我们可以说它们在城内或城外......</p>

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

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

我是否必须将每个属性的类型与它们自己的实体(表)分开,例如公寓表、土地表、房屋表……这样我就可以将它们附加到它们自己的特征上。

或者我是否必须将它们与所有Features合并到一个表“Properties”中,并让另一个表“Type”将每个属性链接到它的类型(如在帖子和类别中)。

还是我必须创建四个表"Properties" "Type" "Features"和一个数据透视表"feature_property"

  • 财产属于一种类型(公寓、土地、房屋……)。
  • 类型有很多属性。
  • 特征有很多属性。
  • 一个属性有许多特征。
4

1 回答 1

1

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

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

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

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

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

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

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

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

于 2016-12-19T11:18:43.323 回答