在 MySQL 中存储“额外”用户数据的最佳方式？答案

【问题标题】：Best way to store 'extra' user data in MySQL?在 MySQL 中存储“额外”用户数据的最佳方式？
【发布时间】：2011-02-07 03:32:09
【问题描述】：

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

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

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

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

另一个想法，这是向我提出的，我已经看到在其他解决方案中使用过（vBulletin 就是其中之一，虽然我看到其他人的名字现在让我忘记了），你只有用户 ID、参考 ID、和一个医学文本字段。我对 MySQL 的了解还不够，不能肯定地说，但是这种方法似乎搜索起来会比较慢，并且可能会有更大的开销。

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

【问题讨论】：

标签： mysql database-design user-accounts

【解决方案1】：

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

1 个中等/长文本或中等/长blob 字段，用于任意文本/二进制存储（无论存储什么 + 字符串长度的 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，都独立于主表存储。

【讨论】：

哇，谢谢，我实际上是要回复第一个同意 #1 的人，选择哪些列 - 但我想我不再需要了 :)。关于您的帖子-您的意思是文本和blob，int和bigint吗？还是其中之一？另外，您对添加 'bool' (tinyint(1)) 列有何感想？我可以看到它非常有用并且可能被大量使用 - 在您看来，节省 3 个字节是否值得？另外，列数是否会增加磁盘上一行的大小？当然是空列。我不怀疑你的（惊人的）表格布局，只是好奇。
我列表中的每个项目各 1 个，因此总共 3 或 4 列，具体取决于您是否需要浮动支持。至于 tinyint(1) - 将它们存储在整数列中。您通过添加 tinyint(1) 浪费了一个字节，而不是保存 3。表中的每一行在 MySQL 中总是具有相同的宽度 - 在大多数其他 RDBMS 中的工作方式相同。（varchars 如何影响这一点有点复杂。）“宽度”也称为“行大小”。

【解决方案2】：

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

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

【讨论】：