redis 一对多

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

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

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