将用户设置存储在表中 - 如何？答案

【问题标题】：Storing user settings in table - how?将用户设置存储在表中 - 如何？
【发布时间】：2010-12-27 09:53:30
【问题描述】：

我为用户设置了大约 200 项设置，其中包括通知设置和用户对对象活动的跟踪设置。问题是如何将它存储在数据库中？每个设置应该是一行还是一列？如果是列，那么表将有 200 个列。如果行，则大约 3 列，但每个用户 200 行 x 甚至 1000 万用户 = 不好。

那么我还能如何存储所有这些设置？注意：这些设置是文本输入和对其他表的 FK 查找的混合。

谢谢。

【问题讨论】：

如果您不需要搜索某个字段，您可以将它们全部序列化并存储在一个文本字段中。对我来说，为每个字段创建一列是可以的。为了改进搜索/选择，您可以将它们拆分为几个表，例如 user_profile、user_inteface_settings、user_...（可以单独使用的表）。 -- 创建一个包含设置的通用表：如果您有很多可选字段并且可能导致 200 * 10 000 000 = 2 000 000 000 行的表，则每行一个（如（uid、字段、值）很有用。
百万 - 提醒您，您应该“接受”对您帮助最大的答案。
我的问题还没有解决。设置太多，这里提到的两种方法都不能正常工作。所以我正在探索其他一些选择，一旦我找到了一些我会接受最接近的答案。

【解决方案1】：

序列化数据几乎总是被证明是一个坏主意，因为这样做会削弱 dbms。用于生产高效 dbms 的所有时间都将浪费在序列化的比特桶上。

如果您有针对每个设置的应用程序逻辑，我认为您应该将其实现为：

设置表中每个设置 1 列。 这使得更容易利用 dbms 的强大功能，包括约束检查、引用完整性、正确的值数据类型以及向优化器提供的大量信息。缺点是行大小会增加。

或

每个设置（或一组相关设置）1 个表格。 这具有上述所有优点，但是当您需要一次获取大部分或所有设置时，会以行大小换取性能损失。当设置是可选的时，如果实际数据稀疏，则此替代方案将显着减小。

此外，很多列通常是一种“异味”，这表明您没有正确规范化数据，但不一定非要如此。只有您知道您的数据。

【讨论】：

很多列是因为“每个用户活动的隐私级别”。每个用户活动都有一个用户定义的隐私级别和一个默认的系统定义的隐私级别。对于系统设置，这很好，但是当我们有 200 个活动时，每个活动都有自己的设置，用户设置就会失控。

【解决方案2】：

您有 200 个设置要跟踪，这表明数据库架构灵活。因此，我建议采用混合方法：

Users：每个用户都有一行的表，其中包含用户可能始终拥有的属性，例如用户名和密码。该表也可能保留外键，但这是一种启发式方法，并且还取决于关系是零对一还是零对多。后者需要单独的表格。
特点：两种选择
1. 每个特征都有行的表，实际上是一个哈希表，包含 userId、name 和 value 列。这也可能是对外关系的一个地方，但您将无法在此设置中强制执行数据完整性。
2. XML，但仅适用于具有允许您查询数据的功能的数据库，或者仅适用于您不需要查询的数据，但只能在您的应用程序服务器上使用。

我认为更大的答案是您不会从原始问题中得出一个解决方案，而是需要同时使用两者来适应数据。

【讨论】：

【解决方案3】：

我认为 200 列绝对不是一个好主意，因为在编写存储过程、手动查看数据或稍后扩展到更多设置方面存在困难。

您能否为所有这 200 个设置尝试 XML，然后每个用户将只有 1 行。用户名和相应的设置 xml。但同样会限制您的查询能力，但 DB 现在支持 XML。您可以专门检查 XML DB。

【讨论】：