我会对您的归因方案采取不同的方法。我不会将不同的属性视为同义词，而是将它们视为重叠的，或者更具体地说，是对属性的嵌套描述。这将处理您的业务案例，同时承认 Mike Sherrill 的敏锐观察。
这是一个快速的 ERD 草图：
通过一个非常快速的数据字典：
PROPERTY 是一块不动产。
CATEGORY 是描述性属性的集合。这张表的重点更多是作为属性的组织者，而不是其他任何东西。它可能包括诸如“财产类型”、“所有权结构”、“浴室数量”之类的内容，以及任何其他可能感兴趣的内容。
ATTRIBUTE 是一种特定的兴趣质量。请注意此实体类型的内卷关系。稍后我会处理更多。要点是属性可以更一般或更具体，并且某些属性可以看作是其他属性的细化。
DESCRIPTOR 是 PROPERTY 和与该特定不动产相关联的 ATTRIBUTE 的交集。
那么这应该有什么帮助呢？
关键是属性如何工作。如果您使用嵌套集模型，那么您可以解决或多或少特定的归因和搜索条件。考虑下一个潜在类别及其相关属性的图表：
在本例中，CATEGORY 是“属性类型”。从图中可以看出，该类别中的属性存在层次结构分解。图中的每个框都是 ATTRIBUTE 中的一条记录。包含其他框的框具有子属性。位于另一个盒子内的盒子对其包含盒子有一个 FK，依此类推。
通过这种方式，您可以说“我想找一处顶层公寓”。然后，您可以找到带有指向“Penthouse”属性的相关描述符的 PROPERTY 记录。这很容易。但是，如果您的搜索结果为空怎么办？
这种方法的优势在于，您可以通过说“让我们将归因层次结构提升到下一个比顶层公寓不太具体的东西”来放松您的标准。在我的例子中，那将是“高层”。现在你再次尝试搜索，你可能会有更好的运气。
这样的系统使您能够在每个归因类别中尽可能具体，同时将其他归因类别放宽到足以开始获得搜索命中。这真的是房地产经纪人的工作，不是吗？帮助客户做出必要的妥协以找到最符合他们最重要标准的方案？
处理嵌套集
这种方法唯一棘手的部分是如何处理嵌套集。有很多方法可以做到这一点，其中许多已在其他地方彻底记录。我自己喜欢visitation number 技术，尤其是对于相对静态的数据集。这使得查找某些给定 ATTRIBUTE 或其任何子项的匹配项变得非常容易，而无需在 SQL 中执行任何奇特的操作。
编辑：那么它是如何工作的？
OP 询问您如何处理诸如卧室数量之类的问题以及查询是什么样的？我们再举一个例子来说明：
上面显示了类别“卧室数”的嵌套集。我还在图表中添加了访问次数。请注意访问数字的工作方式，特别注意任何给定属性值的左（绿色）和右（红色）数字包含任何从属属性的左和右访问数字。例如，“2+ Bedrooms”的左右数字分别为 6 和 15。属于“2+ Bedrooms”的每个属性都有在这个范围内的左右数字。
那么您将如何查询具有给定描述符的属性？假设我们要查找所有有两间或更多卧室的房产。此类查询的 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 来查找特定的相关属性，而是查找属于您的过滤器的任何相关属性 范围。
如果您想过滤多个属性，只需在 where 子句中添加更多子句即可。