我正在开展一个项目，该项目涉及构建一个社交网络式应用程序，允许用户在其网络中共享库存/产品信息（用于采购）。
我是一名体面的程序员，但我确实不是数据库方面的专家;在数据库设计方面更是如此。目前，用户/公司信息通过MySQL中的关系数据库方案存储，该方案运行良好。
我的问题是，虽然我的关系方案能够很好地处理用户/公司信息，但我对如何实施库存信息感到困惑。问题是每个“库存清单”肯定会包含特定于产品类型的不同属性，但与列表中每个其他产品的属性相同。我的第一个想法是为每个“库存清单”创建一个表。但是，我觉得这会非常混乱，并且会使未来对KDD的尝试复杂化。我也（简短）考虑使用'主库存'并存储信息（例如变量类别和数据作为JSON字符串。但我认为JSON字符串MySQL会变成更大的痛苦屁股
我的问题基本上是别人怎么解决这个问题？或者，更一般地说，坚持关系数据库管理的原则，将类似类型的独特大型数据集与父用户相关联的“正确”方法是什么？问题是，我知道我可以很容易地构建一些可行的东西，但我真的对如何解决这个问题的共识感兴趣。
谢谢！
答案 0 :(得分：1)
我会查看这篇文章：Entity Attribute Value Database vs. strict Relational Model Ecommerce
我一直认为这样做的方法是为存储普遍共同字段的库存创建一个基表。产品ID，产品名称等
然后你有另一个具有动态属性的表。一个非常流行的例子是Wordpress。如果你看看他们的数据模型，他们会大量使用这个想法。
这种方法的一个好处是它很灵活。其中一个主要的负面因素是它很慢并且可以产生复杂的代码。
我会抛弃使用文档数据库的替代方法。在这种情况下，每个文档可以具有不同的模式/结构，您仍然可以对它们运行查询。