Bonjour,

Petite question,

Es qu'il est préférable de créer :

- Une table animal et préciser la race et l'espece dans une colonne, avec espece_id et race_id + clé étrangère.

OU

- Une nouvelle table race_espece et mettre dans 3 colonnes l'id de l'animal, l'id de la race, et l'id de l'espece ? Puis créer la clé étrangère de chaque colonne avec l'id de la table race, espece et animals ? 

Je sais pas si c'est clair, mais au lieu de créer une table animal avec espece_id et race_id, je regroupe animal_id, race_id et espece_id dans une meme table race_espece.

Es que la deuxième proposition complique les choses pour les requetes ?

Je fais référence aux cours sur mysql.

Car pour m'entrainé j'ai crée une table article, créateur, categorie. Et le seul moyen que j'ai trouvé pour mettre plusieurs articles a un créateur était de créer une table article_categorie, et lui ajouter l'id du createur et l'id de l'article suivis de l'id de la categorie. 

Ce qui donnerai :

ID créateur | ID article | ID catégorie

       1                  1                  1

       1                  2                  1

etc...

Merci

-
Edité par MickaelSayer 20 janvier 2021 à 9:26:42

Bonjour,

Tu as des animaux, des espèces et des races. 3 entités donc 3 tables.

Un animal est d'une seule race et une race contient plusieurs animaux. Relation 1,n => clé étrangère dans la table animal.

Un race concerne une seule espèce et une espèce contient plusieurs races. Relation 1,n => clé étrangère dans la table espèce.

Le modèle est donc :

• espece ( id_espece [pk], nom )
• race ( id_race [pk], id_espece [fk], nom )
• animal ( id_animal [pk], id_race [fk], date_naissance, nom )

merci,

donc il est préférable de garder la première ou la deuxième solution pour les animaux ? 
Même si je suppose que si la deuxième était meilleur, ils auraient fait le cours de cet manière.

Et pour mon essaie sur le « blog » ? Es que la technique est bonne ? 

Pour les animaux et mon blog, sa me paraissait bien de créer une table pour regrouper les ID xD 

je comprend que le modèle que tu explique est le bon, mais c’est bien de chercher autre chose pour mieux comprendre la meilleure façon de faire. J’ai trouvais une autre manière de faire et les testes que j’ai fais fonctionnent comme sur la 1ère méthode. 

Alors pourquoi pas tout rassembler au même endroit ? ca complique les choses ? 

Un utilisateur peut avoir plusieurs article mais l’article une seul catégorie. 

j’aurais pu ajouter à la table article, une colonne user_id et category_id et donc l’utilisateur aurait pu avoir plusieurs article. Comme pour les animaux. Mais créer une table qui rassemble tous ça serait une solution non ? 

merci en tous cas 

-
Edité par MickaelSayer 20 janvier 2021 à 17:25:20

MickaelSayer a écrit:

donc il est préférable de garder la première ou la deuxième solution pour les animaux ? 

Ni l'une ni l'autre ! Seul le modèle que je te propose est correct ...

MickaelSayer a écrit:

Une table animal et préciser la race et l'espece dans une colonne, avec espece_id et race_id + clé étrangère.

Ce modèle n'est pas correct car il permet d'affecter à un animal une race et une espèce incohérentes. Tu peux saisir l'id de l'espèce "chien" avec l'id de la race "siamois" (qui est une race de chat).

MickaelSayer a écrit:

Une nouvelle table race_espece et mettre dans 3 colonnes l'id de l'animal, l'id de la race, et l'id de l'espece ? Puis créer la clé étrangère de chaque colonne avec l'id de la table race, espece et animals ? 

Ce modèle n'est pas correct pour deux raisons. Il permet d'affecter à un animal une race et une espèce incohérentes (comme vu précédemment), et il permet d'affecter plusieurs races ou plusieurs espèces à un même animal.

MickaelSayer a écrit:

j'ai crée une table article, créateur, categorie. Et le seul moyen que j'ai trouvé pour mettre plusieurs articles a un créateur était de créer une table article_categorie, et lui ajouter l'id du createur et l'id de l'article suivis de l'id de la categorie.

Non, ce n'est aussi pas bon ... il faut en premier lieu te poser la question des cardinalités (cf. doc "Conception BDD" dans ma signature).

Tu as des articles, des créateurs et des catégories, 3 entités = 3 tables.

Un article est affecté à une catégorie, et une catégorie peut contenir plusieurs articles. Relation 1,n => clé étrangère dans article.

Un article a un créateur, et un créateur peut avoir plusieurs articles. Relation 1,n => clé étrangère dans article.

Le modèle serait :

• createur ( id_createur [pk], nom, prenom, date_naissance )
• categorie ( id_categorie [pk], nom )
• article ( id_article [pk], id_createur [fk], id_categorie [fk], titre, contenu )

Maintenant, si l'on voulait qu'un article puisse être associé à plusieurs catégories par exemple, la relation devient :

Un article est affecté à plusieurs catégories, et une catégorie peut contenir plusieurs articles. Relation n,n => table de relation.

Le modèle devient alors :

• createur ( id_createur [pk], nom, prenom, date_naissance )
• categorie ( id_categorie [pk], nom )
• article ( id_article [pk], id_createur [fk], titre, contenu )
• article_categorie ( id_article [pk][fk], id_categorie [pk][fk] )

Merci

je comprend mieux. je teste ça ce soir

c’est dommage que dans le cours SQL il montre pas directement le bon modele. 

Dans le cours il font :

• espece ( id_espece [pk], nom )
• race ( id_race [pk], id_espece[fk], nom )
• animal ( id_animal [pk], id_race [fk], id_espece[fk], date_naissance, nom )

Ton modèle :

• espece ( id_espece [pk], nom )
• race ( id_race [pk], id_espece [fk], nom )
• animal ( id_animal [pk], id_race [fk], date_naissance, nom )

Concernant le modèle du blog j’avais pratiquement la même chose que toi, donc sa me rassure quand même il me manquait juste article_categorie.

j’irai faire un tour sur « conception BDD »

 merci en tous cas

-
Edité par MickaelSayer 20 janvier 2021 à 21:11:19

MickaelSayer a écrit:

c’est dommage que dans le cours SQL il montre pas directement le bon modele.

Oui, mais c'est le fil conducteur de l'apprentissage qui fait que l'on se retrouve progressivement avec ce modèle tordu, c'est juste pour montrer l'évolution d'une table ...