多选字段的数据表结构如何更好的设计?

teamwei
  • 11

一个困扰多年的数据表设计问题,多选字段的表设计,开发中一直采用关联表这种方案,如图

虽然这样的设计没问题,但是如果一件商品有20个多选字段,这样就需要20张关联表,而每张表只是用来保存关联的id值,感觉有点冗余,并且在编辑商品时需要把所有关联的数据都查询出来,在保存的时候需要判断该选项是否新增还是删除,对后端代码的实现也比较复杂。

不知道有没有更好的方案去设计这种多选字段数据表结构,在查询和性能方面达到比较好的平衡性。

有几点要求如下:
1、不采用分隔符,例如:1001,1002,1004,对查询拥有某个属性的商品时不方便
2、不采用二进制,可读性太差
3、能够快速的通关某个选项id查询出该选项下的所有商品
4、可用json格式保存数据,但需要能解决第3点的问题
5、考虑后端增删改查的实现,实现逻辑不要太复杂

回复
阅读 1.8k
3 个回答

了解一下 sku 设计方案,只言片语说不清

仅从查询方面讲的话,其实这样设计也是够的,但是,不能直接这样查,而且使用一些擅长查询的数据库,比如 ElasticSearch(以下简称 ES),在往 ES 写数据前,把这个产品的所有关联关系都查出来,然后丢进 ES ,后续直接从 ES 查询就简单多了。

当数据库数据有更新时,主动更新到 ES ,这样就能保证 ES 和 数据库的基本一致。

没有建议了。

宣传栏