pan*_*nic 3 php mysql database-design
我正在研究本地在线约会网站的下一个版本,基于PHP和MySQL,我想做正确的事情.用户表非常庞大,预计随着新版本的增长会更多,因为在促销上会花费很多钱.
我猜7-8岁的当前版本可能是由不太熟悉PHP和MySQL的人完成的,所以我必须从头开始.
该社区目前拥有20万以上的用户,预计在未来一两年内将增长到500k-1mil.每个用户的个人资料有100多个属性,我必须能够搜索至少30-40个属性.
你可以想象我有点谨慎制作一个有200k行和100列的表格.我的前任将用户表分成两个...一个使用最多和搜索的列,另一个使用列的其余(和批量).但这会导致两个表之间出现大的同步问题.
那么,您认为这是最好的方式吗？
这本身并不是一个答案,但由于这里的答案很少提出属性 - 价值模型,我只是想跳进去说出我的人生经历.
我尝试过一次使用这个模型,一个包含120多个属性的表(每年增长5-10个),并且添加大约10万行(每6个月一次),索引变得越来越大,以至于需要添加或更新单身user_id.
我发现这种类型的设计的问题(不是它完全不适合任何情况)是你需要user_id,attrib在第二个表上放置一个主键.如果不知道attrib的潜在长度,通常会使用更大的长度值,从而增加索引.就我而言,attribs可能有3到130个字符.而且,value最肯定的是遭受同样的假设.
正如OP所说,这会导致同步问题.想象一下,如果每个属性(或至少50%的属性)都需要存在.
此外,正如OP建议的那样,搜索需要在30-40个属性上进行,我不能想象30-40个连接如何有效,甚至是group_concat()由于长度限制.
我唯一可行的解决方案是回到一个包含尽可能多列的列表.我的索引现在变得更小了,搜索也更容易.
编辑:此外,没有规范化问题.要么具有属性值的查找表,要么拥有它们ENUM().
编辑2:当然,可以说我应该有一个属性可能值的查找表(减少索引大小),但我应该在该表上进行连接.