数据库设计：更好地存储更多列，还是在后端使用单个列和字典？

Question

我正在构建一个网络应用程序，该应用程序需要使用首选项并将其保存。

我要保存的数据集将由一个唯一ID，一个搜索字符串和一些有限的参数列表组成，这些参数可以表示为True或False。 参数列表最多可以说10个。

我还没有决定我要使用哪种类型的数据库，但假设它具有行和列，将ID，搜索字符串和所有参数作为单独的列会更有效，或者具有ID，搜索会更有效字符串，然后使用我将在后端翻译的某种字典表示我的所有参数的单个列。

例如，我可以在单列中将选项A，C和D表示为ACD，然后在检索时使用字典在应用程序中使用它。 否则我会在表中使用ColA：True，ColB：False，ColC：True，ColD：True，...，ColN，并在我通过它时使用它

在这两种情况下，在像MongoDB之类的地方选择SQL风格的DB会更有用吗？

Answer 1

答案取决于。 通常，人们使用关系数据库来存储关系信息。 这意味着您有单独的选项和值列。 传统上有两种方法可以做到这一点。

最常见的是规范化形式，其中每个选项在Users表中都有一列。 关键是用户ID，您可以只读取值。 当选项的有限列表变化不大时，这非常有效。 当您想通过选项查询表时，它也非常有用，例如，哪些用户具有特定选项。

另一种方法称为实体属性值（EAV）。 在这种方法中， UserOptions表将为每个用户和每个选项有一个单独的行。 密钥通常由用户/选项对组成（选项本身可能是引用选项主列表的ID）。 这很灵活； 添加值很容易，并且每个用户可以处理无限数量的选项。 缺点是为用户获取所有选项可能很麻烦。 值上没有数据类型验证； 实施检查约束以验证值非常棘手。

第三种方法对于某些目的可能是有用的。 那就是将所有选项存储在一个“字符串”中-更典型的是一个JSON对象。 当您仅将数据库用于其ACID属性并且不需要查询单个选项时，此功能很有用。 您可以将“选项对象”读入您的应用程序，并将其解析为选项。

并且，这是解决问题的方法的三个示例。 还有一些混合方法可以结合来自多个解决方案的元素。

哪种解决方案最适合您，取决于您的应用程序。 如果您只有几个预定选项，那么我会建议第一个建议，即表中每个选项只有一列。

Answer 2

您指定的两个选项都不理想。

将ID，搜索字符串和所有参数放在单独的列中会更有效

这样做的问题不仅在于此假设您具有固定的最大参数数量，而且查询此数据将需要您始终包含每个参数列。 查询示例如下：

SELECT    Id, <other fields>, Param1, Param2, Param3, Param4, ..., Param10
FROM      YourTable
WHERE     <stuff>

在后端尝试检查NULL值时，这可能非常麻烦，并且您可能会遇到没有足够列的情况。 另外，建立索引到每个Param都会增加索引的开销。

简而言之，不要那样做。

或者，使用ID，搜索字符串然后使用我将在后端翻译的某种字典来表示我的所有参数的单个列会更有效。

还有，没有 在查询数据时，这种方法存在很大的问题。 例如，如果要检索带有参数xyz所有记录，则需要构造一个查询，以解析出所有参数并进行比较。 这样的查询无法建立索引，并且性能将很糟糕。 另外，它需要在应用程序层上进行更多编码才能真正理解返回的数据。

拟议的解决方案

您应该为参数创建一个单独的表。 该结构看起来类似于以下内容：

Dataset:                    DatasetParameters:
    Id                          DatasetId
    <Other Fields>              Parameter

假设使用此结构，对于ID 1，您具有参数A ， B ， C和D 您可以在DatasetParameters插入四列：

DatasetId    Parameter
----------------------
1            A
1            B
1            C
1            D

如果以后要添加更多参数，则可以简单地从该表中插入（或删除，如果要删除，则以DatasetId为Dataset表的ID 。

要查询此信息，您需要做的就是使用JOIN ：

SELECT      D.*, P.Param
FROM        Dataset       D
INNER JOIN  DatasetParam  P  ON  D.ID = P.DatasetID