0

好的，这是一个标准的用户表；

全名 | 生日 | 电子邮件 | 用户名 | 密码 | 脸书 | 我的空间 | 推特 | 领英

这没什么不寻常的，它是相当标准的教科书。但是，可以像这样存储它，而不是每个网络都有多个社交网络列；

全名 | 生日 | 电子邮件 | 用户名 | 密码 | 社会的

不同之处在于信息将作为内爆数组而不是单独的列存储在社交列中。这是非常明智的，因此如果有成千上万的用户，肯定会更快地通过脚本进行处理，并且减少对数据库的影响。

谁能想到使用建议的方法而不是教科书方法的任何缺点？

4

1 回答 1

0

我能想到的两个缺点：

  1. 查询特定用户的社交详细信息将更加困难。如果您知道他们的 Facebook 用户名是 fbuser123，那么您可能需要查询类似SELECT * FROM users WHERE social LIKE '%fbuser123%'.
  2. 一旦从数据库中选择了信息，使用起来会稍微困难一些，例如： 要求字段在json_decode使用前被 'ed。

除此之外，我想不出别的了。

我想如果你这样做，存储数据的最有效方式将是 TEXT 格式和json_encode数据。

于 2013-06-09T21:14:30.160 回答