Database design 单表继承，EAV还是NoSQL？

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

目标是存储从客户处收到的项目并报告这些项目。 虽然初始报告将是简单的列表（这些是您的项及其键/值对），但我想为将来对集合的查询做准备，因此我不确定EAV是一种好方法

每个项目都是（重复）类型，并且每个项目都将具有灵活数量的键/值对。 我们有大约15种商品类型，它们不太可能快速增长

键/值对的数量将很低，介于4到20之间，并且（根据需求）不是基于项目类型，而是基于项目所属的客户

为了澄清，客户可能希望我存储物品的状态，而其他客户可能希望我存储颜色或替换id。这取决于具体情况。 因此，我的集合中很可能会有空值，因为每个项目类型都会获得该客户的所有键/值。这使我认为单表继承（具有空值）是可以接受的，但它必须是字段\ 1字段\ 2等，并带有某种映射，因为客户将决定所需键的名称。 我觉得哪个不合适

---

客户项目（及其关键/价值）的集合通常大于20和在您列出的所有三种方法中都完成了项目，我不知道我能给您一个明确的方向，但我可以提供一些关于前进和选择正确方法的建议

小贴士:

如果可以的话，尽量不要混用技术。根据我个人的经验，我发现这是非常困难的。你也会经常读到需要扩展的大型网站，他们总是提到保持架构简单。他们将从MySQL和MongoDB这样的混合体开始，然后抛弃MongoDB以保持简单

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

认识到所有的决定都有后果。您的解决方案的前80%可能相当快速和简单。最后20%将包括妥协，可能相当丑陋。做好准备，接受它

根据我的经验，文档数据库（NoSQL）方法仍然有点风险。在完成了整整一年的文档开发之后，到目前为止，最困难的事情是对数据进行建模。如果你想走这条路，一定要学习数据建模。这会帮你省去很多痛苦

---

谢谢你的见解。关于第2点，我的问题是我不知道接下来需要什么样的报告。现在一个列表就足够了，这在EAV中是完全可以做到的。我担心的是未知场景，不知道NoSQL能否比SQL更好地解决这些问题。这基本上是第三点。我知道使用NoSQL并不是一个神奇的解决方案，我想我可以在以后导出到该格式。