我正在为我的应用程序的数据模型寻找一个理智的方法。 大多数线程专注于电子商务产品，我的情况有所不同。
目标是存储从客户收到的商品并报告回来。 虽然初始报告将是简单列表（这些是您的项目及其键/值对），但我希望为将来对集合的查询做好准备，因此我不确定EAV是一种很好的方法。
每个项目都是（重复）类型，每个项目都有灵活的键/值对。 我们有大约15种商品类型，他们不太可能快速增长。
键/值对的数量将很低，在4到20之间，并且（每个要求）不是基于项目类型，而是基于项目属于的客户。
为了澄清，客户可能希望我存储项目的条件，而另一个人可能希望我存储颜色或替换ID。这真的取决于。 因此，无论如何我很可能在我的集合中都有NULL值，因为每个项目类型都将获得该客户的所有键/值。这让我觉得单表继承（带有NULL值）是可以接受的，但它必须是field_1 field_2等 - 带有某种映射，因为客户将决定所需键的名称（s ）。 哪个对我来说不合适？
客户项目（及其键/值）的集合通常为> 20且<500，因此每个客户的数据集肯定不是很大。
对于应用程序本身（创建客户及其所需字段），在MySQL中使用（半）EAV可能是一个很好的方法，但是将实际收集的项目记录作为“文档”移动到NoSQL数据库中（Redis et all ）进一步处理？
或者是否会使在RDBMS中可以/应该解决的问题复杂化？
我也遇到了这个http://backchannel.org/blog/friendfeed-schemaless-mysql这似乎是一个解决方案但不确定，因为我的数字太低了。
答案 0 :(得分：11)
在你列出的所有三种方法中完成了项目后，我不知道我能给你一个快速而快速的方向，但我可以就前进和选择正确的方法提供一些建议。
提示：
如果可以的话，尽量不要混合技术。从个人经验来看，我发现这非常困难。此外，您还会经常阅读需要扩展的大型网站，他们总是提及保持架构简单。他们将从MySQL和MongoDB之类的东西开始，然后抛弃MongoDB以保持简单。
您的问题似乎正在遭受一些分析瘫痪。 “我可以做XYZ，但这意味着ABC是不可能的。”我建议修复一些关于你的系统的要点/事实，然后开始构建原型。你似乎有很好的想法，但在你开始建设之前，你不会知道它们有多好。
意识到所有决定都会产生影响。您解决方案的前80％可能会非常快速和轻松。最后20％将包含妥协，可能非常难看。只需做好准备就可以了。
根据我的经验，文档数据库（NoSQL）方法仍然存在风险。从完成了一年的文档开发，到目前为止最难的是对数据进行建模。如果你想走这条路，一定要学习数据建模。它会为你带来很多痛苦。