6

我正在为我的应用程序的数据模型寻找一种良好的理智方法。大多数线程都专注于电子商务产品，我的情况有些不同。

目标是存储从客户那里收到的物品并报告它们。虽然初始报告将是简单的列表（这些是您的项目及其键/值对），但我想为将来对整个集合的查询做准备，所以我不确定 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这似乎是一个解决方案，但不确定，因为我的数字太低了。

4

1 回答 1

12

完成了您列出的所有三种方法的项目后，我不知道我可以给您一个硬性和快速的方向，但我可以提供一些关于前进和选择正确方法的建议。

提示：

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

  2. 你的问题似乎有点分析麻痹。“我可以做 XYZ，但这意味着 ABC 是不可能的。” 我建议修复有关您的系统的一些要点/事实，然后开始构建原型。你似乎有很好的想法，但在你开始构建之前你不会知道它们到底有多好。

  3. 意识到所有决定都有后果。您的解决方案的前 80% 可能会相当快速和容易。最后 20% 将由妥协组成，可能非常难看。只需为此做好准备并接受它。

  4. 根据我的经验，文档数据库 (NoSQL) 方法仍然存在一定风险。在完成了坚实的一年文档开发之后，到目前为止，最困难的事情是对数据进行建模。如果您想走这条路，请确保您学习数据建模。它将为您节省很多痛苦。

于 2013-06-03T16:49:50.367 回答