好了，这是一个标准的用户表;
全名|生日| E-Mail |用户名|密码| Facebook | MySpace | Twitter | LinkedIn
这没什么不寻常的，这是相当标准和教科书。但是，与其为每个网络存储多个社交网络列，还不如这样存储;
全名|生日| E-Mail |用户名|密码|社交
不同之处在于信息将作为内爆数组存储在社会栏中，而不是单独的列中。这是非常明智的，所以如果有成千上万的用户，肯定会通过脚本处理更快，对数据库的影响更小。
有谁能想到使用建议的方法而不是教科书方法的缺点吗?
我能想到的两个缺点:
- 查询特定用户的社交细节将变得更加困难。如果你知道他们的Facebook用户名是fbuser123，那么你可能需要查询
SELECT * FROM users WHERE social LIKE '%fbuser123%'之类的东西。 - 一旦从数据库中选择了信息，使用起来会稍微困难一些，例如:要求该字段在使用之前被
json_decode'ed。
除此之外，我想不出别的了。
我想，如果你这样做，最有效的存储数据的方式将是在文本格式和json_encode的数据。