Discussion :

[yurispy]

Bonjour.

Je connais les bases en MySQL, avec jointures, etc. Mais là, je sèche. Je n'ai pas d'idée ou je bloque peut-être pour une bêtise.

Ma requête doit appeler 2 tables.
Jusqu’à présent, je n'avais que l'une des deux dans mon projet, mais avec les évolutions, il faut que j'en appelle une nouvelle et je bloque.

Précédemment, j'avais ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
SELECT *, DATE_FORMAT( travaux.date,  '%d/%m/%Y' ) AS date_fr 
FROM travaux
LEFT JOIN Fiche_culture ON travaux.fiche_culture_id = Fiche_culture.id_fiche_culture
LEFT JOIN engrais ON travaux.produit_id = engrais.id_engrais
LEFT JOIN operateur ON travaux.operateur_id = operateur.id_operateur
LEFT JOIN justification ON travaux.travaux = justification.id_justification
WHERE travaux.fiche_culture_id = ".$post['id']."
ORDER BY `travaux`.`date`, `travaux`.`id_travaux` ASC

Ma table "travaux" a une colonne "produit_id" que je vais chercher dans engrais.
Mais aujourd'hui, j'ai une nouvelle catégorie de produits nommée "phyto".
Comment puis-je faire pour que, suivant l'id, elle aille chercher dans l'une ou l'autre des tables, sachant qu'elles ont un id qui ne sera jamais commun.
"engrais" va de 1 à 9000.
"phyto" va de 9000 à l'infini .
Vu que je n'aurais jamais autant de produits, j'ai de la marge.

Merci pour vos idées de conception, voir un remaniement côté phyto, vu que côté engrais j'aurais à mon avis beaucoup trop de taf.

[pier.antoine]

Bonjour et bonne année.

Quand je lis

sachant qu'elles ont un id qui ne serq jamais commun

je me trompe peut-être mais je me dis qu'il y a un problème de conception.

Vous devriez n'avoir qu'une seule table intégrant et vos produits "engrais", et vos produits "phyto".


Pierre

[SQLpro]

je me trompe peut-être

OUI !

mais je me dis qu'il y a un problème de conception.

OUI !

Vous devriez n'avoir qu'une seule table intégrant et vos produits "engrais", et vos produits "phyto".

non !!!

Vous devez bien avoir deux tables dont l'une hérite de l'autre, car un engrais est bien un produit phyto, mais tous les produits phyto ne sont pas des engrais.

À me lire : http://sqlpro.developpez.com/cours/m...tion/heritage/

Bref, apprenez à modéliser vos bases au niveau conceptuel au lieu de vous jeter bêtement sur des tables....

A +

[pier.antoine]

Désolé, pour l'héritage, notion que je ne maîtrise pas encore assez, visiblement.

Merci pour l'info.

Pierre

[MacFly58]

Bonsoir,

La notion d'héritage est simple à la base. On identifie les cas d'héritage grâce à une astuce bien pratique : le verbe "être". Ainsi la phrase

un engrais est un produit phyto

montre clairement que dès le niveau conceptuel il convient de mettre en oeuvre l'héritage.

[aieeeuuuuu]

Bonjour,

Bah justement non, ce n'est pas si simple !
La preuve, ici, personne n'a apporté de réponse juste !

Il faut bien mettre en place l'héritage, mais il me semble que cette affirmation est fausse :

un engrais est un produit phyto

D'ailleurs, on trouve dans la table phyto beaucoup de colonnes qui ne sont pas dans la table engrais.


Du coup, il faut ici non pas deux mais trois tables :
- PRODUIT avec un id_produit en clef primaire et les colonnes communes aux engrais et aux phyto (libelle, "last_update", utilisation) (d'ailleurs, qu'est-ce que cette colonne "utilisation", et pourquoi n'a-t-elle pas le même type dans les deux tables ?)
- PHYTO, avec id_produit comme clef primaire ET clef étrangère référençant la table produit, ainsi que les colonnes pour les propriétés propres aux produit phyto
- ENGRAIS avec id_produit comme clef primaire ET clef étrangère référençant la table produit, ainsi que les colonnes pour les propriétés propres aux engrais

La table TRAVAUX pourra alors référencer la table PRODUIT.


Pour en revenir à

On identifie les cas d'héritage grâce à une astuce bien pratique : le verbe "être".

ça peut en effet mettre la puce à l'oreille, encore faut-il y penser (ici la notion de produit n'était pas réellement présente,bien que le nom de la colonne clef étrangère dans la table travaux l'évoquait).
Par ailleurs, il faut mettre en place l'héritage seulement si cela a du sens dans le contexte de ce qui est modélisé.

Par exemple ici, on voit que travaux est updatable
On voit également que produit est updatable.
Et on retrouve bien une colonne "last_update" dans les deux tables.
On pourrait effectivement mettre ici en place un héritage, avec une table METTABLE_A_JOUR (ou un autre nom, si vous préférez ) qui contiendrait cette colonne last_update, et dont hériteraient les tables TRAVAUX et PRODUIT.
Mais je pense que ce serait ici un excès de zèle qui pourrait s'avérer couteux en développement, sans présenter le moindre intérêt.


Enfin, je pense qu'il reste d'autres problèmes de modélisation ici : par exemple, je doute que la colonne "principe_actif" ait sa place dans la table TRAVAUX. Je pense qu'elle aurait plutôt dû être initialement dans la table ENGRAIS, et qu’elle devra, en mettant en place l'héritage, être dans la table PRODUIT, puisque la table PHYTO possède la même colonne.