我正在撰写评论网站。基本上，您可以选择位置和业务类型，并可选择按各种业务归因过滤搜索结果。这里有五张桌子：
ID 名称 LocationID
LocationID 地点名称 状态
属性Id 的AttributeName
AttributeValueID ParentAttributeID 的AttributeValue
ID 属性Id AttributeValueID
所以我需要的是根据属性值计算查询以使用（加入？）来获取特定位置的业务。
例如，我想在圣塔莫尼卡找到一位具有以下属性的理发师：
价格：便宜 开放周末：是的 削减女性头发：是的这些属性存储在Attributes和AttributeValues表中，并链接到BusinessAttributes表中的业务。
所以我想说我从搜索表单中得到了这些细节：
LocationID = 5＆安培;价格便宜=＆安培; Open_Weekends =是＆安培; Customs_Womens_Hair =是
我需要构建查询以返回与此位置和属性匹配的商家。
提前感谢您的帮助，我认为StackOverflow非常棒。
答案 0 :(得分：2)
考虑到您的数据需求，您可能是无架构文档数据库的完美候选者。在最近一集.Net Rocks（link to show）中，Michael Dirolf谈到了他的项目MongoDB。
根据我的理解，您可以将每个Business实体存储在数据库中，并使用其所有相关属性（LocationID，Price，Open_Weekends，Customs_Womens_Hair等）。存储在商店中的每个实体可以具有不同的属性组合，因为没有架构。这本身就完成了您尝试使用Attribute和Attribute_Value表所做的事情。
要搜索数据库，只需询问具有您需要的特定键和值集的所有实体。没有复杂的连接，也没有性能损失。您正在做的正是基于文档的基于文档的数据库的设计。
Michael Dirolf：是的，我认为许多正在转换的人都是那些使用关系数据库的角落，就像我们使用MongoDB一样。<登记/> Richard Campbell：对 Michael Dirolf：因此有列，列键和单独的列值，并以这种方式插入东西，以便他们在架构中完成各种疯狂的东西...... 理查德·坎贝尔：是的，现在我正在思考，我突然意识到我只是描述了你的完美客户，一个已经服用过的人，就像他们说的那样滥用SQL Server。我们正走在这条有趣的道路上，你不应该在这里。
如果你继续沿着构建关系属性/值存储的道路前进，你的性能将受到导致的组合爆炸的影响。