我们即将解决客户对基于网络的应用程序的需求，该应用程序拥有大量数量的产品及其数据 - 包括价格，重量，物理volyme等等。
除价格之外的所有内容都是数据，这些数据将被存储一次，然后可能不会更改。另一方面，价格将至少每天更新一次，以适应不断变化的货币汇率。因此，我们已经考虑了一些关于使用noSQL数据库的问题，但我还没有经验来决定它是一个好主意还是只是一个奇特而现代的解决方案？
是吗？非常感谢！
答案 0 :(得分：5)
As Michael explained，根据您的具体要求，关系数据库就足够了。但是，NoSQL数据库可能是更好的解决方案，具体取决于您的要求的两个方面：数据的数量和格式。
如果单个关系数据库服务器可以轻松处理数据量，那么一定要使用该关系数据库。但是，如果您处理的是无法有效处理单个服务器的大量数据，NoSQL解决方案可能是更好的选择。 NoSQL数据库更适合跨服务器分发，因为它们不必处理关系完整性和原子事务等事情。
如果所有产品大致包含相同的属性，并且所有这些属性都可以轻松存储在单个表中，则使用关系数据库。但是，如果数据模型在每个产品类型上存在很大差异和/或产品数据被标准化为多个表并且不能轻易地进行非规范化，则可以使用无模式 NoSQL解决方案（例如文档数据库）是一个更好的选择。然后，您将不必处理大量数据的连接操作。
简而言之，如果您处理的是大量数据，或者处理（部分）无模式的数据，NoSQL绝对是一个可行的解决方案。
请记住，关系数据库也可以通过sharding针对大量数据进行优化。例如，您可以根据SKU将产品拆分为单独的表。然后数据库只需要处理小表，而不是单个大表。这些表可以存储在不同的服务器上以分散负载。
另一种选择是在关系数据库之上使用CQRS architecture。所有数据修改查询都将发送到单个主数据库。然后将这些修改发布到只读数据库或高速缓存，其中包含数据的非规范化表示。在只读数据库上执行数据检索查询以获得更好的性能。虽然这是一个很好的纸质架构，但它确实会对应用程序的整体架构产生相当大的影响。所以除非你以前使用过，否则我不会推荐CQRS。
您的问题没有简单的答案，因为这完全取决于具体要求。我的建议是在项目的设计阶段牢记关系和NoSQL解决方案。如果您意识到关系数据库已足够，那么使用它。如果您意识到使用NoSQL数据库同样容易，那就试试吧。
不是是/否答案，但希望有些食物虽然：）
答案 1 :(得分：2)
虽然noSQL数据库可以解决您的问题，但在我看来，它也适合标准的关系模型。您可能希望将价格设置为一个单独的表，其中1-1连接到主产品表，以便更新的表更小（并且您或数据库可以使用不同的策略来处理这两个表）。