首页新闻找找看学习计划

有关搭配表设计

0
[已解决问题] 解决于 2018-04-28 10:19
 求教数据库设计,比如3件衣服,加上1个装饰,可以拥有无数个(最多存储100个)搭配图效果,然后组合成一套搭配。       查询是,1,查询用户有多个搭配图,按搭配图查出整个搭配展现      2.通过某个衣服id,查询符合的搭配图,并按整体搭配组合展现。 
 那我目前的设计是 
uid 为用户,itemid 为项id,wtype   2为搭配图,4是衣服,1是装饰         但这样纵向设计,加上一些where查询效果不是很理想(3-5s),目前数据千万级别   
光明中的黑手的主页 光明中的黑手 | 初学一级 | 园豆:133
提问于:2017-03-21 14:54
< >
分享
最佳答案
0

为什么不把不同种类的东西放不同表中?你这1啊2啊什么的理解下来就是不同的东西,你这搞到一起去了要满足你查询条件的情况下索引估计不太好加(估计你实际条件甚至还有些group操作等),如果你这只是一张索引表的话那就另当别论了。

如果这是个索引表的话最好看下你实际执行的sql计划,一般情况下通过这个表做出筛选后应该剩的数据量很小,如果表上的索引得当的话应该是没太大问题的。

还有一点你可以考虑下,你所谓的两种查询最后都落在了所谓的搭配图上,如果你这个搭配图数据量很大(你千万级还算一般)或者写入很频繁可以考虑通过这个搭配图的标识id做分片(表)

奖励园豆:5
Daniel Cai | 专家六级 |园豆:10374 | 2017-03-22 10:08

因为当时没想到数据有这么多,只是刚试运行已经是千万了,预估会成百倍增长,所以肯定不适合,不过目前大半年预估是应该再50亿以内的数据量。

按你说的分表这样,关联join的话也会很慢的,因为实际业务比这复杂的多,它本身还要join 其他业务表。

目前考虑nosql的方案做整改。

光明中的黑手 | 园豆:133 (初学一级) | 2017-03-22 11:19

@光明中的黑手: 分片中主要的就是要规避join,宁可做数据上的冗余也要把join干掉

nosql不能解决你的问题,如果建模不正确,索引不对就算全量到内存中一样不行的。

Daniel Cai | 园豆:10374 (专家六级) | 2017-03-22 11:48

哦,是麽,不是很清楚这块技术,我去了解了解,谢谢!

光明中的黑手 | 园豆:133 (初学一级) | 2017-03-22 11:51
清除回答草稿
   您需要登录以后才能回答,未注册用户请先注册