Bas*_*sit 3 mysql sql optimization multiple-columns
我的桌子上有40多个栏目,我必须添加更多的字段,如当前城市,家乡,学校,工作,大学,拼贴画..
这些用户数据将被拉到许多匹配用户,这些用户是共同的朋友(与其他用户朋友加入朋友表以查看共同的朋友)以及谁没有被阻止以及谁还不是用户的朋友.
上面的请求有点复杂,所以我认为将额外的数据放在同一个用户表中进行快速访问是个好主意,而不是在表中添加更多连接,这会使查询速度降低.但我想得到你的建议
我的朋友告诉我添加额外的字段,这些字段不会在一个字段上作为序列化数据进行搜索.
ERD图:
一些建议
像往常一样 - 这取决于.
首先,MySQL可以支持最大数量的列,而你真的不想到达那里.
其次,如果你有很多带索引的列,那么插入或更新会对性能产生影响(虽然我不确定这在现代硬件上是否重要).
第三,大型表通常是所有与核心实体相关的数据的倾销场; 这很快使设计不清楚.例如,您提供的设计显示3个不同的"状态"类型字段(status,is_admin和fb_account_verified) - 我怀疑有一些业务逻辑应该将它们链接在一起(例如,管理员必须是经过验证的用户),但是设计不支持.
这可能是也可能不是问题 - 它更像是一个概念性的架构/设计问题,而不是一个性能/它是否有效.但是,在这种情况下,您可以考虑创建表以反映有关帐户的相关信息,即使它没有x对多关系.因此,您可以创建"user_profile","user_credentials","user_fb","user_activity",所有这些都由user_id链接.这使它更整洁,如果你必须添加更多与facebook相关的字段,它们将不会在表的末尾悬挂.但是,它不会使您的数据库更快或更具可扩展性.连接的成本可能微不足道.
无论你做什么,选项2 - 将"很少使用的字段"序列化为单个文本字段 - 是一个可怕的想法.您无法验证数据(因此日期可能无效,数字可能是文本,非空值可能会丢失),并且"where"子句中的任何使用都会变得非常慢.
一种流行的替代方案是"实体/属性/价值"或"钥匙/价值"商店.此解决方案具有一些优点 - 即使您的架构发生更改或在设计时未知,您也可以将数据存储在关系数据库中.但是,它们也有缺点:在数据库级别(数据类型和可空性)验证数据很困难,使用外键关系很难与其他表进行有意义的链接,查询数据会变得非常复杂 - 想象一下状态为1且facebook_id为空且注册日期大于昨天的记录.
鉴于您似乎知道数据的架构,我会说"键/值"不是一个好的选择.
