我在这里看到了一些关于存储用户首选项的问题，但它们似乎主要指的是一组相当少的首选项。我目前正在开发一个高度可定制的网络应用程序，该应用程序需要存储大量首选项，而我正在为如何存储它们而苦苦挣扎。
我将存储的首选项类型包括用于显示特定工具提示的布尔值、页面上各种内容面板的排列、登录后要显示的页面、特定表单字段的默认值等。总而言之，我预计每个用户会有 50 多个这种类型的偏好，数据主要是布尔值和整数。
我不是序列化的忠实拥护者，但我担心将每个首选项存储为单独的行的可扩展性。想法？
【问题讨论】：
标签： database scalability preferences
序列化数据块是这里的方法，但不是出于性能原因，而是因为这是系统的一个方面，可能会发生大量变化。您不希望仅仅因为您现在需要允许首选项在某些页面或其他内容上打开高级模式，就必须更改您的数据库架构。
HLGEM 提到的实体-属性-价值模型从“易于发展”的角度来看符合这一点，但正如她所说，它的性能会很差。
您将放弃使用序列化对象将能够直接查询数据库以查找与特定模式匹配的用户（也许您正在追踪一个仅在某些设置组合下才会发生的错误，并且您想看看是否您有任何具有该组合的用户）。
【讨论】：
无论您做什么，都避免为此使用实体属性值结构 (http://en.wikipedia.org/wiki/Entity-Attribute-Value_model)，除非您想要一个性能非常糟糕的系统。调用一个有 50 列的表比调用一个表要快得多，你必须加入 50 次才能获得所需的所有信息。
我会根据您打算如何查询首选项（如果您想在登录时撤回所有首选项）为每组一般首选项（登录首选项、整体站点首选项、特定页面或功能首选项）制作一个相关表副拉那些在登录时整个站点所需的那些和那些仅在用户点击它们时才用于特定区域的那些，所以它们的某种组合）并在其中设置了偏好类型的布尔列。这样，网站每个区域所需的所有首选项都将位于同一个表中或最多两个或三个表中，从而相对容易获取信息。这是设计对性能至关重要的一个地方（您将一直在查找偏好，所以甚至毫秒数），因此您确实应该在设计中首先考虑性能。在这里，它比任何希望使它看起来是面向对象的或在设置中为开发人员创建更少的工作量都重要得多。
【讨论】：
如果您不需要搜索首选项，您可以始终将首选项存储为 XML 并将其保存到“首选项”列。应该使将来添加新的偏好更容易一些；）
【讨论】：
我什至不知道我是否会将用户偏好等信息存储在数据库中。一旦用户登录，您似乎会想要查看许多（如果不是全部）用户偏好；如果你最终做了一堆数据库查询，你的系统最终会很慢。相反，我建议将用户的所有设置保存在单个文件（或某处的单个记录）中，并在用户登录后立即将其全部吞下并缓存。
【讨论】：
假设用户数据已经存储在数据库中，那么我认为将它们全部存储在一行中没有任何真正的问题，特别是如果您可能需要根据数据进行查询，即。选择所有偏好 A 或 B 等的用户。
不过，我会将其加载到一个类中，并通过某种缓存机制持久化该类。
【讨论】：
您可以做的另一个选择（如果您不需要将项目存储在数据库中，例如检查数据的统计信息（谁做了什么等）），您可以将所有设置放入 cookie 并存储它在他们的机器上。
当然，cookie 带来了使用 cookie 的所有注意事项。但只是另一个想法......
【讨论】：
用户更喜欢某些偏好（所有动物都是平等的，但有些动物比其他动物更平等）。这些应该专门针对登录界面上的检索和应用进行优化。随着偏好深度的下降，它们可以使用任何标准聚合并保存为单独的列，可能作为数组保存（例如，字体偏好列包括字体类型、大小和颜色，并引用字体表）。还可以使用 db 工具对频繁使用的列进行索引，并重新设计以拆分聚合列，以便您可以确定聚合中的哪个元素需求量很大。
总而言之，用户偏好往往是非常静态的（即就像一种习惯），不要将高度可变的用户数据与偏好混淆。
【讨论】：