单表继承,EAV还是NoSQL？

Question

我正在为我的应用程序的数据模型寻找一个理智的方法.大多数线程专注于电子商务产品,我的情况有所不同.

目标是存储从客户收到的物品并报告给他们.虽然初始报告将是简单列表(这些是您的项目及其键/值对),但我希望为将来对集合的查询做好准备,因此我不确定EAV是一种好方法.

每个项目都是(重复)类型,每个项目将具有灵活数量的键/值对.我们有大约15种商品类型,他们不太可能快速增长.

键/值对的数量将很低,在4到20之间,并且(每个要求)不是基于项目类型,而是基于项目所属的客户.

为了澄清,客户可能希望我存储项目的条件,而另一个人可能希望我存储颜色或替换ID.这真的取决于.因此,无论如何我很可能在我的集合中都有NULL值,因为每个项目类型都将获得该客户的所有键/值.这让我觉得单表继承(带有NULL值)是可以接受的,但它必须是field_1 field_2等 - 通过某种映射,因为客户将决定所需键的名称.哪个对我不合适？

客户项目(及其键/值)的集合通常将> 20且<500,因此每个客户的数据集肯定不是很大.

也许在MySQL中为应用程序本身(创建客户及其所需的字段)中的(半)EAV是一种很好的方法,但是将实际收集的项目记录作为"文档"移动到NoSQL数据库(Redis等所有)中以进一步处理？

或者这是否可以/应该在RDBMS中解决的问题复杂化？

我也遇到了这个http://backchannel.org/blog/friendfeed-schemaless-mysql这似乎是一个解决方案但不确定,因为我的数字太低了.

Answer 1

在你列出的所有三种方法中完成了项目,我不知道我能给你一个快速而快速的方向,但我可以提出一些关于前进和选择正确方法的建议.

提示:

1. 如果可以,尽量不要混合技术.从个人经验来看,我发现这非常困难.此外,您还会经常阅读需要扩展的大型网站,他们总是提到保持架构简单.他们将从MySQL和MongoDB之类的东西开始,然后抛弃MongoDB以保持简单.

2. 你的问题似乎正在遭受一些分析瘫痪."我可以做XYZ,但这意味着ABC是不可能的." 我建议修复一些关于你的系统的要点/事实,然后开始构建原型.你似乎有很好的想法,但在你开始建造之前,你不会知道它们到底有多好.

3. 实现所有决策都有后果.您解决方案的前80%可能会非常快速和轻松.最后20%将包含妥协,可能非常难看.只需做好准备就可以了.

4. 根据我的经验,文档数据库(NoSQL)方法仍然存在风险.从完成了一年的文档开发,到目前为止最难的是对数据进行建模.如果你想走这条路,一定要学习数据建模.它会为你节省很多痛苦.