在MySQL中存储"额外"用户数据的最佳方法？

Question

我正在为我的用户模块添加一个新功能用于我的CMS并且我遇到了障碍......或者我想,这是一个岔路口,我想在我做任何事情之前从stackoverflow获得一些意见.
基本上我想让管理员添加新的"额外"用户字段,用户可以在注册时填写,在他们的个人资料中编辑,和/或由其他模块控制.这方面的一个例子是生日场,对自己的冗长描述,或者用户在网站上获得的积分.不用说,存储的数据将是变化的,并且可以从大量文本到小整数值.更糟糕的是 - 我希望有搜索这些数据的选项.

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

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

我更喜欢这个,因为它会使搜索速度明显加快,并且参考表(其中包含所有字段的数据,例如字段的名称,是否可搜索等)可以引用当应该使用哪个列时存储该字段的数据.

另一个想法,建议给我,我已经看到用于其他解决方案(vBulletin是一个,虽然我已经看到其他人的名字目前逃避我),你只有你的用户ID,参考ID和一个medtext领域.我不太清楚MySQL是否可以肯定地说这个,但是这种方法似乎比搜索速度慢,并且可能有更大的开销.

那么哪种方法"最好"？我还缺少另一种方法吗？无论我最终使用哪种方法,它都需要快速搜索,而不是大规模(一点点开销很好),并且最好允许使用针对数据的复杂查询.

Answer 1

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

• 1 个中/长文本或中/长blob 字段，用于任意文本/二进制存储（无论存储什么内容+字符串长度的 3-4 个字节的开销）。选择中型而非长型的唯一原因是将可存储的内容限制为 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 值（例如长文本）都独立于主表存储。