我在促销产品行业工作。我们出售几乎任何你可以打印，绣花，雕刻或任何其他方法来定制。流行的产品是钢笔，马克杯，衬衫，帽子等。因为我们有各种各样的产品，存储有关这些产品的信息，包括所有可能的产品选项，装饰选项和所有相关的额外费用变得极其复杂。尽管如此，尽管许多人已经尝试过，但没有人能够提供行业产品数据，以便您可以通过算法将数据转换为电子商务商店，而无需进行一定程度的数据按摩。在关系数据库中正确存储此信息似乎几乎不可能。 我很好奇MongoDB或任何其他NoSQL选项是否允许我以比MySQL等RDBMS更容易存储和操作我们的产品信息的方式对信息进行建模。该公司我工作的时间超过100年，并且多年来一直在AS400上使用DB2。我需要一些很好的理由来说服他们使用非关系数据库解决方案。
我们行业中常用的产品是Bic Clic Stic Pen，它有20多种颜色可供选择，每种颜色可选用于桶身和修剪颜色。更多颜色可供丝网印刷选择。然后，您可以为要使用的墨水类型选择其他选项。包装有多种选择。选择完所有选项后，您还可以选择加急处理。所有这些选项可能会或可能不会产生额外费用，这些费用可能取决于您订购的笔数量或装饰中的颜色数量。定价通常基于数量，因此订购250支钢笔每支笔的成本将高于订购1000支。同样，当您订购1000支订购笔时，每笔订购特殊墨水的额外费用会更便宜。
答案 0 :(得分：2)
不想听起来很苛刻，这有一个银弹问题的戒指。
您拥有固有的复杂业务领域。我不清楚存储数据的不同方式会对这种复杂性产生任何影响 - 如果客户订单超过250，那么存储文档而不是关系数据可能不会使您的笔价格降低0.02美元。 / p>
我建议关注业务领域，而不要过多担心存储机制。我是领域驱动设计的忠实粉丝 - 这听起来像是这种方法的完美案例。
答案 1 :(得分：1)
使用文档数据库并不能完全解决您的问题，但它可能会有所帮助。
如果您的文档代表了产品上可用的选项和该产品的订单，那么在大多数情况下，您将整体访问该文档 - 这不是您无法使用SQL，而是非常适合文档数据库。由于文档的结构是灵活的，因此在不更改数据库的情况下，将文档中的对象定义为复杂类型来定义特定选项或规则相对容易。
然而，这只会对数据有所帮助 - 您的真正问题是在UI方面。这两个文档一起直接映射到订单表单，但无论您使用哪种方法来定义选项/规则，某些产品最终都会出现极其复杂的设置页面。
答案 2 :(得分：1)
是的，MongoDB就是您所需要的。它没有严格的文档结构，因此您可以创建所需的模型集，并以您需要的任何顺序和组合将它们嵌入到产品页面中。实际上它可以使用这些数据而不直接描述真实的模型字段，所以我（例如）可以使用我的Rails应用程序根本不知道的字段。
MongoDB也很容易设置复制和分片。它还支持GridFS虚拟文件系统，因此您可以使用描述它们的文档存储产品的图像，并轻松地将它们作为单个对象进行操作。
你一定要试一试。
UPD：无论如何，最好保留RDBMS以获取财务数据和处理数字，例如为销售分析等分组报告。 NoSQL基础不是很擅长。