MongoDB是否适合我的行业?

| 我从事促销产品行业。我们出售几乎所有您可以打印,绣花,雕刻或其他任何可自定义的方法。流行的产品是笔,杯子,衬衫,帽子等。由于我们的产品种类繁多,因此存储有关这些产品的信息(包括所有可能的产品选项,装饰选项以及所有相关的额外费用)变得极为复杂。如此之多,以至于尽管许多人都进行了尝试,但是没有人能够以某种方式提供工业产品数据,从而可以在不进行一定程度的数据按摩的情况下将数据算法化为电子商务商店。将这些信息正确地存储在关系数据库中似乎几乎是不可能的。我很好奇,如果MongoDB或任何其他NoSQL选项允许我以一种比MySQL之类的RDBMS更好地更好地存储和操纵我们的产品信息的方式来建模信息。我工作的公司已有100多年的历史,并且在AS400上使用DB2已有很多年了。我需要一些充分的理由说服他们使用非关系数据库解决方案。 Bic Clic Stic Pen是我们行业使用的常见示例产品,每种笔筒和装饰色都有20多种颜色选择。丝网印刷装饰可选择更多颜色。然后,您可以为要使用的墨水类型选择其他选项。包装有多种选择。选中所有内容后,您便可以进行紧急处理的其他选项。所有这些选项都可能会或可能不会产生额外的费用,具体取决于您订购的笔数或装饰中的颜色数。定价通常基于数量,因此订购250支钢笔比订购1000支钢笔要贵。类似地,订购1000支钢笔比购买250支钢笔,获得特殊墨水的额外费用会便宜。     
已邀请:
        不想听起来刺耳,这有个难题。 您具有一个固有的复杂业务领域。对我来说还不清楚,以不同的方式存储数据会对这种复杂性产生任何影响-如果客户订购的数量更多,则存储文档而不是关系数据可能不会更容易将笔的价格降低0.02美元超过250。 我建议您专注于业务领域,而不要过多地担心存储机制。我是“域驱动设计”的忠实拥护者-听起来很适合这种方法。     
        使用文档数据库无法完全解决您的问题,但可能会有所帮助。 如果您的文档代表某个产品上可用的选项以及该产品的订单,则在大多数情况下,您将整体上访问该文档-使用SQL无法做的一切,但非常适合文档数据库。由于文档的结构是灵活的,因此在不更改数据库的情况下将文档内的对象定义为复杂类型以定义特定选项或规则相对容易。 但是,这仅对数据有帮助-您真正的问题在UI方面。这两个文档直接直接映射到订购单,但是无论您使用什么方法定义选项/规则,某些产品最终都会具有极其复杂的设置页面。     
        是的,MongoDB是您所需要的。它没有严格的文档结构,因此您可以创建所需的模型集并将其按所需的任何顺序和组合嵌入到产品页面中。实际上,可以在不直接描述实际模型字段的情况下使用此数据,因此(例如)我可以使用Rails应用程序根本不了解的字段。 同样,MongoDB极其容易设置用于复制和分片。它还支持GridFS虚拟文件系统,因此您可以使用描述它们的文档存储产品的图像,并轻松地将它们作为单个对象进行操作。 您绝对应该尝试一下。 UPD:无论如何,最好将RDBMS保留为财务数据和关键数据,例如为销售analysys分组报表等。 NoSQL的基础不是很好。     

要回复问题请先登录注册