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