多选字段的数据表结构如何更好的设计？
一个困扰多年的数据表设计问题，多选字段的表设计，开发中一直采用关联表这种方案，如图
虽然这样的设计没问题，但是如果一件商品有20个多选字段，这样就需要20张关联表，而每张表只是用来保存关联的id值，感觉有点冗余，并且在编辑商品时需要把所有关联的数据都查询出来，在保存的时候需要判断该选项是否新增还是删除，对后端代码的实现也比较复杂。
不知道有没有更好的方案去设计这种多选字段数据表结构，在查询和性能方面达到比较好的平衡性。
有几点要求如下：
1、不采用分隔符，例如：1001,1002,1004，对查询拥有某个属性的商品时不方便
2、不采用二进制，可读性太差
3、能够快速的通关某个选项id查询出该选项下的所有商品
4、可用json格式保存数据，但需要能解决第3点的问题
5、考虑后端增删改查的实现，实现逻辑不要太复杂
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
了解一下 sku 设计方案，只言片语说不清
仅从查询方面讲的话，其实这样设计也是够的，但是，不能直接这样查，而且使用一些擅长查询的数据库，比如 ElasticSearch（以下简称 ES），在往 ES 写数据前，把这个产品的所有关联关系都查出来，然后丢进 ES ，后续直接从 ES 查询就简单多了。
当数据库数据有更新时，主动更新到 ES ，这样就能保证 ES 和 数据库的基本一致。
没有建议了。