mysql - Il existe une relation plusieurs-à-plusieurs entre une table et plusieurs tables. Comment la concevoir?

Question

Récemment rencontré un problème lié à une table et plusieurs tables,

Par exemple : il existe maintenant une table d'application app_table, et il existe de nombreuses tables de matériaux Material_table1, Material_table2...
Pour chaque table de matériaux, un matériau peut être utilisé par plusieurs applications, et une application peut également utiliser plusieurs matériaux. Chaque table de matériaux et table d'application ont cette relation et il n'existe aucune association entre chaque table de matériaux.

Évidemment c'est plusieurs à plusieurs, mais le problème est que si la table est créée selon plusieurs à plusieurs, une table intermédiaire doit être créée pour chaque table de matériaux.

J'ai maintenant une idée, qui est d'ajouter un champ à la table d'application, et d'ajouter un champ pour chaque matériau. Le champ stocke les identifiants des matériaux
appartenant à cette application, séparés par des virgules. Mais le problème est que dans ce cas, vous devez interroger deux fois, d'abord filtrer les champs de la table d'application, puis filtrer les données interrogées en fonction des conditions.

Je ne sais pas si vous avez de meilleurs plans ou idées, merci à tous

---

La description est un peu floue. Chaque catégorie de matériaux (une table de matériaux) a une interface. Cependant, lorsque les matériaux sont renvoyés, il faut les filtrer selon l'application, et il existe une application qui utilise plusieurs matériaux (un). table des matériaux), plusieurs matériaux), un matériau peut être utilisé par plusieurs applications. L'état actuel est que chaque table de matériaux a un champ d'application ajouté pour la distinguer, mais cela nécessite l'ajout de nombreuses entrées. J'ai donc réfléchi à l'opportunité de réaliser un tableau d'application, puis de réaliser un tableau d'association pour chaque matériau. De cette façon, lors d'une demande, vous pouvez d'abord rechercher les données dans la table d'application en fonction du nom d'application du paramètre de demande, puis rechercher les données qualifiées dans la table de matériaux appropriée en fonction de l'association.
Je ne sais pas s’il existe une meilleure façon.

Answer 1

Tout d'abord, il y a quelque chose qui ne va pas dans la conception de la structure de votre table. Plusieurs matériaux, pourquoi avez-vous besoin de plusieurs listes de matériaux sur votre CV ? Vous pouvez utiliser le type de matériau pour le distinguer.
Je ne sais pas pourquoi vous voulez diviser les matériaux en tableaux. Si c'est le cas, je suppose que c'est parce que les types de matériaux sont différents, je pense que le tableau devrait être construit comme ça

.

app Table d'applicationapp 应用表
material 素材表
material_type 素材类型
app_materialmaterial Table de matériaux

material_type Type de matériau#🎜🎜#app_material Tableau des relations d'application des matériaux#🎜🎜#

Answer 2

J'ai l'impression de n'avoir besoin que d'une seule table d'association :

Table d'association
ID d'application Table de matériau ID ID de matériau
01 07 08

Vous pouvez déterminer quels matériaux sont utilisés par une application

Answer 3

Tucao : D'où vient le plusieurs-à-plusieurs ? Les champs de chaque table de matériaux sont différents. La table d'application a une relation plusieurs-à-plusieurs avec un certain type de table de matériaux (éléments de la table de matériaux). ), mais la table d'application a une relation plusieurs-à-plusieurs avec tous. La table matérielle n'est pas une relation plusieurs-à-plusieurs, c'est une relation d'inclusion ou de non-inclusion

.

Answer 4

Tout d'abord, selon votre idée, votre table de données sera très volumineuse et difficile à maintenir à l'avenir. Il est recommandé de convertir les propriétés des matériaux en json ou de les sérialiser pour le stockage.

Answer 5

Pour les relations un-à-plusieurs, on utilise généralement un tableau intermédiaire, et uniquement pour les relations un-à-un, une colonne sera ajoutée pour représenter la relation

Answer 6

A A_ID A_OTHER
B B_ID B_OTHER
C C_ID C_OTHER
REF REF_ID(序列) A B C D E …

1                        
2                        
3                        
4                        
5                        

Answer 7

app_id | nom_table_matériel |

Mot clé, association polymorphe