-
业务的逻辑是，为用户分配品牌。用户搜索商品，只能搜索出对应品牌的商品。
-
我现在的做法是： 先查出用户有品牌权限的商品集合。然后查询时条件带上 in(goodsList)。
-
这种做法，效率太低了。请问有什么好的思路吗？
This topic created in 2258 days ago, the information mentioned may be changed or developed.
 |
zzw252Sep 4, 2020
1
启用或登录时返回用户信息中带上权限集合，请求商品列表时回传权限集给后端？
|
 |
wj219Sep 4, 2020
2
商品里边有存品牌 id 么，条件用 in (用户有权限的品牌 id) 至少执行的 SQL 长度小一点
|
 |
nuttingSep 4, 2020
3
1L 馊主意，权限怎么能前端确定。这没啥思路，就是表关联，条件限制啊。你是说 in 这个做法 sql 低效？
|
 |
voneSep 4, 2020
4
拿把菜刀架在用户脖子上，然后说请不要点开没权限的商品。
或者 select * from 商品表 join 商品品牌表 on m=n join 品牌权限表 on x=y |
 |
locozSep 4, 2020
5
 后端做效率太低辣，让前端在界面上直接隐藏没权限的商品（狗头保命） |
 |
gaiusSep 4, 2020 via Android
6
搞个用户商品权限范围表，查询时实时获取，用 es 查，不知道有多少商品，想想还挺恐怖的
|
 |
pushbackSep 4, 2020
9
create table (user) - (user_goods) - (goods)
select g.* from user_goods ug left join goods g on ug.goods_id = g.id where ug.user_id = ? |
 |
OrangutanSep 4, 2020
14
楼主没有说清楚效率低具体是低在哪里? 瓶颈在哪里?
如果是查询慢,同楼上,一般索引,sql 优化下,如果还是解决不了,可以将用户和相关品牌权限存入缓存. 直接从缓存拿到关系直接单表 in 查询,前提注意缓存更新维护 |
 |
redteaSep 4, 2020
16
一个品牌一个库
|
 |
vencent00Sep 4, 2020
17
用户组不是太多的话把用户组对应的商品 id 存 redis，查询慢的话就上 es 吧，除了价格都走 es 查。
|
 |
yufeng0681Sep 4, 2020
21
业务体验方面：搜索结果的前两页没有命中用户的诉求，后面一百页都没有人翻看。
如果是淘宝类的商品 用户会加筛选条件看前两页（比如筛选地区，筛选信用度，筛选销售量） 前期没啥商品，性能够用，怎么搞都可以；后面肯定要上 ES 来做更复杂的搜索逻辑，性能就不需要考虑了。 除非你们钱多，请个 DBA 来优化 SQL |
 |
xuanbgSep 5, 2020
22
搞一个商品分组，权限和分组相关，然后联表查询吧。。。效能降低那是肯定的，但也没有更好的办法了。
|
Select Language