添加了多个过滤器后将向用户显示的数据的SQL vs NoSQL

Question

我将要从事一个超出我正常职责范围的工作项目。作为一个SQL
DBA，我最初的意图是使用SQL数据库来处理该项目，但是我对NoSQL的了解越多，我就越相信它可能是更好的选择。我希望我可以用这个问题来高层次地描述该项目，以获得有关使用每个选项的利弊的一些反馈。

该项目相对简单。我有一组具有各种属性的对象。这些属性中的某些属性是所有对象共有的，而某些属性仅是对象的子集所共有的。我负责构建的是一项服务，其中用户根据对象的属性选择一系列过滤器，然后返回与所有过滤器匹配的对象列表。当用户选择过滤器时，他或她可能正在对common或subset属性进行过滤，但该过滤器是在前端进行抽象的。

^根据用户反馈，有可能对象列表可能仅与某些过滤器匹配，并且匹配质量将通过指示匹配多少个标准的分数显示给用户。

看完MartinFolwler的演讲后，文档样式的NoSQL数据库似乎可以满足我的需求，但是鉴于我对这种方法没有经验，我也有可能遗漏了一些明显的东西。

一些其他信息-
数据库最初将有大约5,000个对象，每个对象包含10到50个属性，但是对象的数量肯定会随着时间的推移而增长，并且属性的数量可能会根据用户反馈而增长。另外，我希望能够在收到用户反馈时对产品进行快速更改，因此灵活性非常重要。

任何反馈将不胜感激，如果我在讨论中遗漏了任何重要信息，我将很乐意提供更多信息。谢谢。

Answer 1

也可以将此作为答案。我应该评论说，我在NoSQL方面不强，所以我倾向于使用SQL。

我会以三张桌子的形式来做这件事。您会在网络上看到它被称为实体值对逻辑的一种……这是一种处理项目的多个动态属性的方法。假设您有一堆产品，每个产品都有一些属性。

Prd 1 - a,b,c
Prd 2 - a,d,e,f
Prd 3 - a,b,d,g
Prd 4 - a,c,d,e,f

因此，这里有4个产品和6个属性…相同的理论适用于数百个产品和数千个属性。将其保存在一个表中的标准方法需要产品信息以及6列来存储数据（在此设置中，至少有三分之一为空）。添加新属性意味着更改表以在表中添加另一列，并提出一个脚本来填充现有表或仅将其保留为所有现有表为空。不是最有趣的，可能是头痛。

替代方法是设置名称/值对。您想要一个“表头”表来保存产品之间的通用值（例如名称或价格…所有产品都具有的东西）。在上面的示例中，您会注意到在每个记录上都使用了属性“
a”……这确实意味着属性a也可以是标头表的一部分。我们将此处的关键列称为“ header_id”。

第二张表是一个参考表，它仅用于存储可以分配给每个产品的属性并为其分配ID。我们将使用atrr_id作为关键字调用table属性。直截了当，上面的每个属性都是一行。

快速示例：

attr_id, attribute_name, notes
1,b, the length of time the product takes to install
2,c, spare part required
etc...

它只是所有属性及其含义的列表。将来，您将在此表中添加一行以为每个标题打开一个新属性。

最终表是实际上包含信息的映射表。您将拥有您的产品ID，属性ID，然后是值。通常称为明细表：

prd1, b, 5 mins
prd1, c, needs spare jack
prd2, d, 'misc text'
prd3, b, 15 mins

看看数据如何存储为产品密钥，价值标签，价值？将来添加的任何产品都可以具有此表中存储的任何属性的任意组合。添加新属性是在属性表中添加新行，然后根据需要填充详细信息表。

我相信这里也有一个wiki … http://en.wikipedia.org/wiki/Entity-attribute-
value_model

在此之后，它只是想出最好的方法来处理您的数据（我建议在这里将Postgres作为开源db选项）