Question

我正在选择一种数据库方法，但仍处于非常高级别的决策阶段。由于其庞大的成熟度和功能集，我正在尽力使我的问题适合Postgres，但我完全不熟悉这种SQL复杂度，想知道我心中的核心关系是否可能在不同的模型中更好地表达。（我仅在给定的框架内找到其他询问此问题的答案。）

（在较大的设置范围内）驾驶问题是能否将由特定分类器（模型）分配的功能（例如，大，重，类型，但其中的一组变化）与事物相关联。这些不仅仅表明事物是“大型”的，而且还被特定的分类器评估为“大型”。在RDBMS中最困难的是，“大”的值可能是二进制的，而“权重”是整数，“类型”是类别等。换句话说，

 Thing1 --> large=true   (says model 1)
        |-> weight=3     (says model 2)
        |-> type='great' (says model 3)

 Thing2 --> large=false (says model 1)
        (not assessed for 'weight')
        |-> type='lousy' (says model 4)

简而言之，存储（事物，特征，值，分类器）元组，其中事物和特征是多对多的，并且对于不同的特征，值将具有不同的类型。

方法1：关系性

有一张桌子。还有一个PARENT类的Feature，该类（或它的子类）与Things具有多对多关系。每个特定的要素（大，重量，类型）都是CHILD的“要素”类，并且每个子>-<事物结点表也为该特定特征保存事物（统一键入）的值。换句话说，

ThingTypeValues
-------------------
thing.id | type.id | 'great'
thing.id | type.id | 'lousy'
...

ThingLargeValues
---------------------
thing.id | large.id | true
thing.id | large.id | false
...

这使我能够获取所有的“ thing.features”，因为它们作为父项共享Feature，并且仍在查询表中具有一致类型的同时查询Thing的完整（混合类型）描述；通过使每个Feature-child成为自己的表（而不是对象中的仅字符串），它还使我（更好）避免了意外出现“ great”，“ grreat”和“ Great”的问题。或不断更新的ENUM），通过将每个功能视为受人尊敬的独立身份事物，我可以轻松地检查标签的现有选项。

最后一点，如果只有一个分类器（应用功能的东西），那么可能会有一个表，每个列都是一个功能，并且每个单元格都有一个值或NULL来表示它不是“对此功能进行了评估-但由于实际上会有大量模型，每个模型都有自己的见解，这听起来像是一个非常丑陋的策略，因为每个模型都有自己的庞大，大部分为空且始终在增长的模型（如我们添加了更多功能），表格。

但是，例如，使用SQLAlchemy（到目前为止，我对python最为熟悉），我现在不得不使用association_object和AbstractConcreteBase，在我未经训练的人看来，它们看起来都非常讨厌

**方法2：NoSQL **

突然出现混合问题，这似乎是最大的问题，不再是问题！我可以具有一组功能，每个功能都有一个类型和一个值，并将每个功能与答案相关联。如果我想避免对类别进行繁琐操作，可以使用一个功能来验证它们，或者在添加新功能之前先检查现有功能。当然，这些听起来更容易出错，但是我问这是因为我不知道如何评估权衡，如何在EITHER框架中寻求最佳解决方案，或者无论如何，完全不同的想法还是更好的主意。 / p>

欢迎大家提出意见，建议，技术，理念和捐赠。

多态多对多数据库策略的比较：RDB与NoSQL

0 个答案: