这本身并不是一个答案,但由于这里的答案很少提出属性 – 价值模型,我只是想跳进去说出我的人生经历.
我尝试过一次使用这个模型,一个包含120个属性的表(每年增长5-10个),并添加大约10万行(每6个月一次),索引变得越来越大,以至于需要添加或更新一个单个user_id.
我发现这种类型的设计的问题(不是它完全不适合任何情况)是你需要在user_id上放置一个主键,在第二个表上.如果不知道attrib的潜在长度,通常会使用更大的长度值,从而增加索引.就我而言,attribs可能有3到130个字符.此外,价值肯定受到相同的假设.
正如OP所说,这会导致同步问题.想象一下,如果每个属性(或至少50%的属性)都需要存在.
此外,正如OP建议的那样,搜索需要在30-40个属性上进行,我不能想象30-40个连接是如何有效的,或者甚至是由于长度限制的group_concat().
我唯一可行的解决方案是回到一个包含尽可能多列的列表.我的索引现在变得更小了,搜索也更容易.
编辑:此外,没有规范化问题.要么具有属性值的查找表,要么具有ENUM().
编辑2:当然,可以说我应该有一个属性可能值的查找表(减少索引大小),但我应该在该表上进行连接.