• 关于

    redis 一对多

    的搜索结果

问题

redis一对多的实现?

最近在学习使用redis,在关系型的mysql下一个简单的一对多,很简单,如下用户表user主表idnameage1 jack 5 2 rose 12 3 dad 23 图片表pics从表iduidimg_url1 1 ./1zxcz12a...
爵霸 2019-12-01 20:10:51 2814 浏览量 回答数 1

问题

相关 redis缓存结构设计问题

最近准备将所有数据统统放入redis中,以减少数据库查询次数。 现需要将简历的信息存入redis中,使用hash结构来保存姓名,性别,年龄,工作年限。 每一份简历还有包含多个标签(tag),还包含多个图片、视频等媒体资源,还有工作经验、学习...
落地花开啦 2019-12-01 19:48:19 1471 浏览量 回答数 1

问题

在非关系型数据库如何设计“多对一”?

现在存文章内容用hash类型:`post:$post_idtitle, content ...comment:$comment_idcontent, date, statusposts:$post_id, $comment_id`存了一个h...
落地花开啦 2019-12-01 20:03:00 915 浏览量 回答数 1

万券齐发助力企业上云,爆款产品低至2.2折起!

限量神券最高减1000,抢完即止!云服务器ECS新用户首购低至0.95折!

问题

怎么设计“多对一”在非关系型数据库

现在存文章内容用hash类型:post:$post_id title, content ... comment:$comment_id content, date, status post...
爵霸 2019-12-01 20:11:05 1176 浏览量 回答数 1

回答

商品分类可以参考主流电商平台的设计,比如淘宝、京东之类的,简单点可以是树形结构,如: 女装 上衣 T恤 衬衫 ... 裤子 休闲裤 打底裤 短裤 ... 裙装 A字裙 连衣裙 ... 这种结构相对较为简单,本质上为一对多的关系,单表即可表示,通过父ID建立上下级关联,做Redis缓存设计时,可以简单的使用SET集合来实现 category:女装 => <上衣,裤子,裙装,...>category:女装:上衣 => ...如果是多对多结构的,如:T恤可属于上衣分类,也可属于夏装分类,此类结构,可以在分类表外多建一张关系表,用于表示多对多的关系,分类元数据仍然可以只使用一张表表示,不需要父ID字段,但在做Redis缓存设计时,稍微麻烦一点 父级与子级结构(SET) category:上衣 => category:夏装 => 子级与父级结构(SET) category:T恤:parents => <上衣,夏装>category:衬衫:parents => <上衣,夏装>使用上述结构的原因是,维护缓存时,节点的变更会同时影响到上下级,所以上级对下级、下级对上级的关系都应有所表示,便于维护。假如上述案例中,要删除T恤分类,就需要根据T恤分类找到所有父类,再将父类下的T恤节点移除,如果需要删除夏装分类,则反回来需要查出所有夏装子节点,具体是要移除子结点还是其它处理逻辑则应根据业务需要来定。
爵霸 2019-12-02 02:00:21 0 浏览量 回答数 0

回答

NoSQL很少能完整的支持Join功能,所以在NoSQL里一般用denormalized form存储展开后的关系,因此这个关系不再是“多对一”,而是“一对多”。你可以用集合类型存储子文档,比如Redis里的list或set,MongoDB里的sub-document等。对于NoSQL,有一个简单的原则,就是把有关联的东西放在一起,比如文章和评论,注意,如果有可能,尽量把文章和评论的所有属性包括内容放在一起,而不是只在文章的记录中存储评论的id。这样做的好处很明显,你只需要一次读操作就可以获取这篇文章相关的所有数据,无论怎样进行数据切分也不会把文章和它相关的东西分开到不同的物理机,这样可以极大的提高后台的可缩放性。当然这样的设计并不总是适合你的应用,比如文章和作者之间的关系也许就没办法完全的denormailize,所以你需要仔细考虑数据展现的方式和流程,来决定到底该如何组织数据。总之,NoSQL不是万灵药,它在提供更高的灵活性、可缩放性和性能的同时,也把原来的黑盒数据库简化成了白盒存储引擎,你需要自己在各个因素之间找到最适合的平衡点,这个工作确实需要很多经验和对业务的深入理解。当然,如果数据量很小,这都不是事儿。
落地花开啦 2019-12-02 01:54:28 0 浏览量 回答数 0

回答

NoSQL很少能完整的支持Join功能,所以在NoSQL里一般用denormalized form存储展开后的关系,因此这个关系不再是“多对一”,而是“一对多”。你可以用集合类型存储子文档,比如Redis里的list或set,MongoDB里的sub-document等。对于NoSQL,有一个简单的原则,就是把有关联的东西放在一起,比如文章和评论,注意,如果有可能,尽量把文章和评论的所有属性包括内容放在一起,而不是只在文章的记录中存储评论的id。 这样做的好处很明显,你只需要一次读操作就可以获取这篇文章相关的所有数据,无论怎样进行数据切分也不会把文章和它相关的东西分开到不同的物理机,这样可以极大的提高后台的可缩放性。 当然这样的设计并不总是适合你的应用,比如文章和作者之间的关系也许就没办法完全的denormailize,所以你需要仔细考虑数据展现的方式和流程,来决定到底该如何组织数据。总之,NoSQL不是万灵药,它在提供更高的灵活性、可缩放性和性能的同时,也把原来的黑盒数据库简化成了白盒存储引擎,你需要自己在各个因素之间找到最适合的平衡点,这个工作确实需要很多经验和对业务的深入理解。当然,如果数据量很小,这都不是事儿。
爵霸 2019-12-02 02:01:33 0 浏览量 回答数 0

问题

程序员报错行为大赏-配置报错

Maven本地仓库配置报错:配置报错  GO语言配置什么的都没问题,但就是LiteIDE配置不好。。。:配置报错  Maven 配置nexus仓库 POM文件报错:配置报错  10个你可能从未用过的PHP函数:配置报错  QT...
问问小秘 2020-06-11 13:18:25 6 浏览量 回答数 1

云产品推荐

上海奇点人才服务相关的云产品 小程序定制 上海微企信息技术相关的云产品 国内短信套餐包 ECS云服务器安全配置相关的云产品 开发者问答 阿里云建站 自然场景识别相关的云产品 万网 小程序开发制作 视频内容分析 视频集锦 代理记账服务