最近遇到了一个表和多个表关联的问题，
例如 : 现在有一个应用表 app_table，有很多个素材表 material_table1、material_table2... ，
对每个素材表来说，一个素材可能有多个应用使用，一个应用也可以使用多个素材。每个素材表和应用表都是这种关系，而且每个素材表之间没有任何关联。
显然是多对多，但问题就是如果按照多对多建立表的话，每个素材表都要建立一个中间表。
我现在有个想法，就是在应用表中添加字段，每个素材都添加一个字段，字段中保存着这个 app 所拥有的素材
的 id，按照逗号隔开。但是问题就是这样的话要查询两次，先通过应用表的字段进行筛选，然后再按照条件对查询出来的数据进行筛选。
不知道大家有没有更好的方案和想法，谢谢大家啦
描述的有点不清楚，是每个类别的素材(一个素材表)都做一个接口，只不过素材返回的时候是要根据应用来筛选的，而且存在一个应用使用多个素材(一个素材表中的多个素材)，一个素材可能有多个应用使用。现在的状态是每个素材表都添加了一个应用字段来区分，但是这样要添加很多条目进去。所有我考虑要不要做一个应用表，然后每个素材做一个关联表。这样请求的时候可以先根据请求参数的应用名来查到应用表的数据，再根据关联去查到相关素材表中符合条件的数据。
不知道有没有更好的方法。
首先你这个表结构设计的有点问题。多个素材，为什么要简历多个素材表？可以使用素材类型来区分吧。
我不知道你为什么要给素材分表，如果安我猜的是因为素材类型不同，我觉得建表应该是这样的
app应用表app应用表material素材表material_type素材类型app_materialmaterial素材表material_type素材类型🎜app_material素材应用关系表🎜感觉只需要一个关联表：
关联表
应用ID 素材表ID 素材ID
01 07 08
就可以确定某个应用使用了哪些素材
吐槽一句:哪里来的多对多啊.每个素材表的字段都不一样.应用表对某类型的素材表(素材表的元素)是多对多关系,但是应用表跟所有的素材表直接不是多对多关系,是包含跟不包含的关系好不.
首先，按照你的思路 你数据表将来很庞大难以维护，建议可以把素材的属性转成json或者序列化进行存储.
一对多的关联关系我们一般会使用中间表，一对一的才会增加一列来表示关系
A A_ID A_OTHER
雷雷B B_ID B_OTHER
C C_ID C_OTHER
REF REF_ID(序列) A B C D E …
app_id | material_table_name | material_table_id
关键字，多态关联