我会对你的归因方案采取不同的方法。我不会将不同的属性视为同义词，而是将它们视为重叠，或者更具体地说，nested属性的描述。这将处理您的业务案例，同时承认迈克·谢里尔（Mike Sherrill）的敏锐观察。
这是一个快速的 ERD 草图：
通过非常快的数据字典：
PROPERTY是一块房地产。
CATEGORY是描述性属性的集合。该表的意义更多的是作为属性的组织者而不是其他任何东西。它可以包括“财产类型”、“所有权结构”、“浴室数量”以及其他任何可能感兴趣的内容。
ATTRIBUTE是一种特定的兴趣品质。请注意此实体类型上的内卷关系。稍后我会详细讨论这个问题。要点是属性可以更一般或更具体，并且某些属性可以被视为其他属性的细化。
DESCRIPTOR是财产和与该特定房地产相关的属性的交集。
那么这应该有什么帮助呢？
关键是属性如何发挥作用。如果您使用嵌套集合模型，那么您可以或多或少地解决具体的归因和搜索条件。考虑以下一个潜在类别及其相关属性的图表：
在此示例中，CATEGORY 是“财产类型”。从图中可以看出，该类别中的属性按层次结构细分。图中的每个方框都是ATTRIBUTE中的一条记录。包含其他框的框具有子属性。位于另一个盒子内的盒子与其包含的盒子有一个 FK，依此类推。
这样，您可以说“我想找到一套顶层公寓”。然后，您可以找到具有指向“阁楼”属性的相关描述符的 PROPERTY 记录。这很容易。但如果您的搜索结果为空怎么办？
这种方法的优点是，您可以通过说“让我们将归因层次上升到下一个比顶层公寓不太具体的事物”来放宽您的标准。在我的示例中，这将是“高层建筑”。现在您再次尝试搜索，您可能会有更好的运气。
这样的系统使您能够在每个归因类别中尽可能具体，同时充分放松其他类别以开始获得搜索命中。这确实是房地产经纪人的工作，不是吗？帮助客户做出必要的妥协，找到最适合他们最重要标准的方案？
处理嵌套集
这种方法唯一棘手的部分是如何处理嵌套集。有很多方法可以做到这一点，其中许多方法已在其他地方详细记录。我自己就喜欢访问次数 http://www.sitepoint.com/hierarchical-data-database-2/技术，特别是对于相对静态的数据集。这使得很容易找到某些给定 ATTRIBUTE 或其任何子属性的匹配项，而无需在 SQL 中执行任何特殊操作。
编辑：那么这是如何工作的？
OP 问你如何处理卧室数量等问题以及查询是什么样的？我们再举一个例子来说明：
上面显示了“卧室数量”类别的嵌套集。我还将访问次数添加到图表中。请注意访问编号的工作方式，特别注意任何给定属性值的左（绿色）和右（红色）数字包含任何从属属性的左和右访问编号。例如，“2+ Bedrooms”的左右数字分别为 6 和 15。属于“2+ 卧室”的每个属性都有属于此范围的左侧和右侧数字。
那么如何查询具有给定描述符的属性呢？假设我们想要查找具有两间或更多卧室的所有房产。此类查询的 SQL 可能如下所示：
select P.*
from PROPERTY P
inner join DESCRIPTOR D
on P.id = D.property_id
inner join ATTRIBUTE A
on D.attribute_id = A.id
where A.left >= (select X.left from ATTRIBUTE X
where X.name = '2+ Bedrooms')
and A.right <= (select Y.right from ATTRIBUTE Y
where Y.name = '2+ Bedrooms')
请注意，上面的查询与您实际使用的查询略有不同。例如，您可能会使用其 int 标识键而不是字符串名称来查找过滤属性。但是，我想我应该将其保留为如图所示，以便清楚地了解要点，即您可以通过查看进行过滤not对于特定的相关属性，但对于属于您的过滤器的任何相关属性range.
如果您想过滤多个属性，只需向 where 子句添加更多子子句即可。
