6

我正在为我的 CMS 的用户模块添加一个新功能，但我遇到了障碍......或者我猜，这是一个岔路口，我想在我承诺任何事情之前从 stackoverflow 获得一些意见。
基本上，我希望允许管理员添加新的“额外”用户字段，用户可以在注册时填写这些字段，在他们的个人资料中进行编辑，和/或由其他模块控制。这方面的一个例子是生日字段、对自己的冗长描述，或者用户在网站上获得的积分。不用说，存储的数据会有所不同，范围可以从大量文本到小的整数值。更糟糕的是 - 我希望有搜索这些数据的选项。

有了这个 - 最好的方法是什么？现在我倾向于有一个包含以下列的表格。

userid, refFieldID, varchar, tinyint, smallint, int, text, date, datetime, etc.

我更喜欢这个，因为它可以显着加快搜索速度，并且引用表（其中包含所有字段的数据，例如字段的名称，是否可搜索等）可以引用应该使用哪个列存储该字段的数据。

另一个想法是向我提出的，我已经看到在其他解决方案中使用过（vBulletin 就是其中之一，尽管我看到其他人的名字现在让我不知道），你只有用户 ID、参考 ID 和一个 medtext场地。我对 MySQL 的了解还不够，无法肯定地说，但是这种方法似乎搜索速度会慢一些，并且可能会有更大的开销。

那么哪种方法是“最好的”？我还缺少另一种方法吗？无论我最终使用哪种方法，它都需要快速搜索，而不是海量（一点点开销就可以了），并且最好允许对数据使用复杂的查询。

4

2 回答 2

3

我同意键值表可能是最好的解决方案。我的第一个倾向是只存储一个文本列，就像 vBulletin 一样。但是，如果您想添加数据存储的功能，使其像您所布置的那样更具可扩展性和可搜索性，我可能会建议：

  • 1 个 medium/longtext 或 medium/longblob 字段，用于任意文本/二进制存储（无论存储什么 + 字符串长度的 3-4 字节开销）。选择中长的唯一原因是将可以存储的内容限制为 2^24 字节 (16.7 MB) 与 2^32 字节 (2 GB)。
  • 1 个整数（4 个字节）或 bigint（8 个字节）
  • 1 个日期时间（8 个字节）
  • 浮点存储可能是 1 个浮点数或双精度数（4-8 字节）

这些字段将允许您在表中存储几乎任何类型的数据，但不会增加表**的宽度（就像 varchar 那样）并避免任何冗余存储（例如具有 tinyint 和 mediumint 等）。存储在长文本字段中的文本仍然可以使用全文索引或常规有限长度索引（例如index longtext_storage(8)）进行合理搜索。

** 所有 blob 值，例如 longtext，都独立于主表存储。

于 2011-02-07T04:00:22.810 回答
0

一种可能对您有用的技术是将这些任意数据存储为文本，使用 JSON、XML 或 YAML 等符号。这个决定取决于您需要如何访问数据：如果您只查找每个用户的全部用户数据，它可能是理想的。如果您需要对用户数据中的特定字段运行 SQL 查询，则需要使用纯 SQL 或混合方法。

许多较新的、高度可扩展的“NoSQL”系统似乎更喜欢 JSON 数据（例如，MongoDB、CouchDB 和 Project Voldemort）。它简洁明了，您可以创建任意复杂的结构，包括地图（JSON 对象）和列表（JSON 数组）。

于 2011-02-07T04:02:10.913 回答