在MySQL中存储“额外”用户数据的最佳方法？
我为我的CMS添加了一个新功能到我的用户模块，并且我碰到了一个障碍......或者我猜想，这是一条叉路，我希望在我承诺之前从stackoverflow得到一些意见任何东西。
基本上我想允许管理员添加新的'额外'用户字段，用户可以在注册时填写，编辑他们的配置文件，和/或由其他模块控制。一个例子就是生日字段，对自己的长篇描述，或者用户在网站上获得的积分。不用说，存储的数据将会变化，并且可以从大量文本到小整数值。更糟糕的是 - 我希望可以选择搜索这些数据。在MySQL中存储“额外”用户数据的最佳方法？
这样就行了 - 最好的办法是什么？现在我倾向于拥有一张带有以下列的表格。
userid, refFieldID, varchar, tinyint, smallint, int, text, date, datetime, etc.
我宁愿这个，因为它会使显著搜索速度更快，并参考表（它包含所有字段的数据，如字段名的，不管是搜索还是没有等）在存储该字段的数据时应参考使用哪一列。
另一个想法，这是我建议和我见过的其他解决方案中使用（vBulletin是一个，虽然我看到别人的名字逃脱我在这一刻），你刚才有用户名，参考ID ，和medtext字段。我对MySQL的确切知之甚少，但这种方法似乎会让搜索速度变慢，并且可能会有更大的开销。
那么哪种方法是'最好的'？我还有其他方法吗？无论我最终使用哪种方法，它都需要快速搜索，而不是大规模（只需少量开销即可），并且最好允许针对数据使用复杂的查询。
我同意键值表可能是最好的解决方案。我的第一个想法是只存储一个文本列，就像vBulletin一样。但是，如果你想添加的能力，为数据存储是有点更具扩展性和可搜索，就像你摆出来，我可能会建议：对于任意的文本
- 1中/ LONGTEXT或中等/ LONGBLOB场/二进制存储（无论是存储+字符串长度为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等）。存储在longtext字段中的文本仍然可以使用全文索引或常规有限长度索引（例如index longtext_storage(8)）进行合理搜索。
**所有blob值（如longtext）都独立于主表存储。
可能适用于您的一种技术是将此任意数据以文本形式存储，如JSON，XML或YAML。这个决定取决于你如何访问数据：如果你只查看每个用户的全部用户数据，它可能是理想的。如果您需要在用户数据的特定字段上运行SQL查询，则需要使用纯SQL或混合方法。许多新的高度可扩展的“NoSQL”系统似乎都倾向于使用JSON数据（例如，MongoDB，CouchDB和Project Voldemort）。它很好也很简洁，您可以创建任意复杂的结构，包括地图（JSON对象）和列表（JSON数组）。
哇谢谢，我实际上会回复第一个同意＃1的人，哪个列可以选择 - 但我想我不必再去了:)。关于你的帖子 - 你的意思是文字和blob，int和bigint？或者一个或另一个？另外，如何添加'bool'（tinyint（1））列？我可以看到它非常有用，并且可能用得很多 - 在你看来，值得保存3个字节吗？ 另外，列数是否会增加磁盘上某一行的大小？当然空列。我不怀疑你的（惊人的）桌面布局，只是好奇而已。 – Jon 2011-02-07 04:05:44