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