我正在为我的用户模块添加一个新功能用于我的CMS并且我遇到了障碍......或者我想，这是一个岔路口，我希望在我提交之前从stackoverflow获得一些意见任何事情。
基本上我想允许管理员添加新的“额外”用户字段，用户可以在注册时填写，在其配置文件中进行编辑，和/或由其他模块控制。这方面的一个例子是生日场，对自己的冗长描述，或者用户在网站上获得的积分。不用说，存储的数据将是变化的，并且可以从大量文本到小整数值。更糟糕的是 - 我希望有搜索这些数据的选项。
有了这个 - 最好的方法是什么？现在我倾向于拥有一个包含以下列的表格。
userid, refFieldID, varchar, tinyint, smallint, int, text, date, datetime, etc.
我更喜欢这个，因为它会使搜索速度明显加快，并且参考表（包含所有字段的数据，例如字段的名称，是否可搜索等）可以引用哪个列应该在存储该字段的数据时使用。
另一个想法，建议给我，我已经看到用于其他解决方案（vBulletin是一个，虽然我已经看到其他人的名字现在逃避我），你只有你的用户ID，参考ID，和一个medtext字段。我不太清楚MySQL是否可以肯定地说这个，但是这种方法似乎比搜索速度慢，并且可能有更大的开销。
那么哪种方法“最好”？我还缺少另一种方法吗？无论我最终使用哪种方法，它都需要快速搜索，而不是大规模（一点点开销很好），并且最好允许使用针对数据的复杂查询。
答案 0 :(得分：3)
我同意键值表可能是最好的解决方案。我的第一个倾向是只存储一个文本列，就像vBulletin那样。但是，如果你想增加数据存储的能力，使其更具有可扩展性和可搜索性，我可能会建议：
这些字段允许您在表中存储几乎任何类型的数据，但不会膨胀表**的宽度（就像varchar一样）并避免任何冗余存储（如使用tinyint和mediumint等）。存储在longtext字段中的文本仍然可以使用全文索引或常规有限长度索引（例如index longtext_storage(8)）进行合理搜索。
**所有blob值（例如longtext）都独立于主表存储。
答案 1 :(得分：0)
可能适用于您的一种技术是将此任意数据存储为文本，以JSON，XML或YAML等符号表示。这个决定取决于您需要如何访问数据：如果您只查找每个用户的完整用户数据块，那么它可能是理想的。如果需要在用户数据的特定字段上运行SQL查询，则需要使用纯SQL或混合方法。
许多较新的，高度可扩展的“NoSQL”系统似乎更喜欢JSON数据（例如，MongoDB，CouchDB和Project Voldemort）。这很好，很简洁，你可以创建任意复杂的结构，包括地图（JSON对象）和列表（JSON数组）。