mysql - 在 MySQL 中存储 'extra' 用户数据的最佳方式？

Question

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

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

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

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

另一个想法，这是向我建议的，我已经看到在其他解决方案中使用过(vBulletin 就是一个，虽然我看到其他人的名字现在让我忘记了)，你只需要用户 ID，引用 ID，和一个 medtext 字段。我对 MySQL 了解不够，无法肯定地说出这一点，但这种方法似乎搜索速度较慢，并且可能有更大的开销。

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

Answer 1

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

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

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

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