SQL - Je n'utiliserai jamais du INNER/RIGHT JOIN sauf en cas de force majeure

[randriano]

Bonjour,

En tant que développeur, je n'utilise que du LEFT JOIN (ou en plus long LEFT OUTER JOIN). Jamais du RIGHT OUTER JOIN, encore moins INNER JOIN qu'en cas de force majeure qui ne se présente pas beaucoup dans le monde professionnel.

Pour la suite, je m'inspire des paroles de mes collègues:
imaginez 2 tables Eleves et Notes, Eleves a 3 enregistrements: titi toto tata, toto n'a pas passé d'examen donc aucune instance dans Notes, INNER JOIN l'exclura du résultat alors qui dit qu'il ne doit pas être affiché en tant que note = zéro

Le cas est plus grave pour les organismes d'attribution des pensions de retraite et de prévoyance sociale: imaginez qu'une personne n'est jamais considérée faute d'un champ non rempli ....

Pour le cas du RIGHT JOIN, c'est juste une manière de penser, c'est l'équivalent du LEFT JOIN mais d'un point de vue inversé!
Imaginez qu'il faut lister les restaurants ayant des plats de plus de 100€, est-ce que vous allez penser: j'image les plats de 100€ ayant pour restaurant ...

Sincèrement,

Rija Randriano

[william44290]

Je constate qu'effectivement je ne code que du left join.

[Oishiiii]

LEFT JOIN et RIGHT JOIN c'est strictement la même chose....

Code :

1
2
table1 LEFT JOIN table2
  ON table1.id = table2.id

est equivalent à

Code :

1
2
table2 RIGHT JOIN table1
  ON table1.id = table2.id

Right (droite) et Left (gauche) font simplement référence à la position dans l'ordre de lecture du texte, de la table qui verra toutes ses lignes retournées dans le résultat...

Vous n'utilisez pas de jointures interne ? Si toutes les requêtes que vous devez exprimer ont se besoin.... pourquoi pas.

Où est le débat ?

Je suis non fumeur, je ne me sert pas du cendrier dans la voiture.....

PS: Je trouve tout de même étonnant de ne jamais utiliser de jointure interne. C'est ce que j'utilise principalement, c'est indispensable lorsque la base de données est bien conçue.

[madfu]

PS: Je trouve tout de même étonnant de ne jamais utiliser de jointure interne. C'est ce que j'utilise principalement, c'est indispensable lorsque la base de données est bien conçue.

+1

imaginez 2 tables Eleves et Notes, Eleves a 3 enregistrements: titi toto tata, toto n'a pas passé d'examen donc aucune instance dans Notes,

Imaginons que je ne veuille que les élèves notés, dans ce cas intérêt du LEFT JOIN ?

[randriano]

Envoyé par madfu

Imaginons que je ne veuille que les élèves notés, dans ce cas intérêt du LEFT JOIN ?

Si c'est un cas de force majeure!!!!!
En tant que développeur travaillant pour des projets clients, il vaut mieux tout garder (donc éviter le inner join) et faire le filtrage au niveau du code (C++, VB.NET, PHP) pour afficher ou pas les sans notes.

C'est vrai au niveau performance et utilisation mémoire, INNER JOIN c'est plus léger mais je préfère utiliser LEFT JOIN car utiliser INNER peut causer une grave conséquence au niveau des données or les données sont importantes

[madfu]

En tant que développeur travaillant pour des projets clients, il vaut mieux tout garder (donc éviter le inner join) et faire le filtrage au niveau du code (C++, VB.NET, PHP) pour afficher ou pas les sans notes.

Déléguer le traitement au code client (au sens client du serveur) ou au SGBD est un choix de conception mais certainement pas une régle

Moi ce que je te dis c'est que tu as un SGBD dont tu ne te sers que partiellement, c'est dommage, ça te fait écrire un code plus lourd pour rien ça surcharge le serveur pour rien mais bon après si ça ne gêne ni toi ni tes clients ni ton admin système pourquoi pas hein

INNER peut causer une grave conséquence au niveau des données or les données sont importantes

Alors si tu as une perte au niveau des données c'est simplement que tu mal compris la demande le INNER JOIN est une jointure stricte si ta demande est stricte "je ne veux que élèves notés" alors le INNER JOIN fera le travail de façon stricte.
Ce qui peut causer une grave conséquence au niveau de la perte des données c'est un mauvais code (SQL ou autre) ou un crash système mais certainement pas le INNER JOIN.

[Marco46]

Envoyé par randriano

Si c'est un cas de force majeure!!!!!
En tant que développeur travaillant pour des projets clients, il vaut mieux tout garder (donc éviter le inner join) et faire le filtrage au niveau du code (C++, VB.NET, PHP) pour afficher ou pas les sans notes.

Tu rajoutes des lignes de codes totalement inutiles qui n'ont rien à y faire.

Le rôle des requêtes est de manipuler la BDD.
Quand tu fais un SELECT c'est pour récupérer les données.
Tu récupères les données, toutes les données, et rien que les données.

Les cas où l'utilisation du INNER à la place d'un LEFT sont légions dans le monde professionnel. Je l'utilise tous les jours, comme j'utilise LEFT tous les jours. Ça dépend des cas.

Bref, ton racisme (si tu me passes l'expression) des INNER je le trouve tout à fait irrationnel et je te mets les -1 que tu mérites

[randriano]

Envoyé par madfu

Déléguer le traitement au code client (au sens client du serveur) ou au SGBD est un choix de conception mais certainement pas une règle

Moi-même je confirme que ce n'est pas une règle mais pour nous, l'INNER JOIN n'est que dans un cas de force majeure car on préfère obtenir tout du SELECT et ne pas manquer une seule ligne qui pourrait être utile.

C'est vrai LEFT JOIN est plus lent et bouffant de la mémoire que INNER JOIN mais on considère toute donnée importante sauf si c'est le client qui confirme qu'il veule du INNER, là c'est différent

[calagan99]

Envoyé par randriano

Moi-même je confirme que ce n'est pas une règle mais pour nous, l'INNER JOIN n'est que dans un cas de force majeure car on préfère obtenir tout du SELECT et ne pas manquer une seule ligne qui pourrait être utile.

C'est vrai LEFT JOIN est plus lent et bouffant de la mémoire que INNER JOIN mais on considère toute donnée importante sauf si c'est le client qui confirme qu'il veule du INNER, là c'est différent

Mais quand tu manipules des tables avec plusieurs millions d'enregistrements, ramener des lignes inutiles et gérer leur exclusion d'un résultat par le code ne me paraît pas un choix des plus pertinents...

[el_slapper]

C'est juste une question de spécifications.

Si l'utilisateur veut tout, pourquoi pas des jointures externes?

Si il ne veut que les clients disposant d'un compte parfaitement renseigné et d'une proposition commerciale existante, la jointure externe n'est d'aucune utilité, là ou la jointure interne, à l'ancienne, prend tout son sens.

Il faut juste savoir ce que l'on veut. Et choisir son outil en fonction.

[aieeeuuuuu]

Envoyé par randriano

Bonjour,
qui dit qu'il ne doit pas être affiché en tant que note = zéro

Et bien, celui qui défini les spécifications par exemple.

Si tu fait une jointure externe avec un COALESCE(Note, 0), si titi a eu 12, et que tata a eu 12 aussi, quand tu vas calculer la moyenne a l'exam, tu obtiendra... 8 !
Donc, pour ne pas pas vouloir "perdre des données" (que tu n'as de toute façon pas, soit dit en passant, puisque toto n'a pas passé l'examen), tu as faussé celles que tu avais !

Certes, il peut être nécessaire pour afficher les notes que toto ne soit pas "zappé", mais après cela dépend du besoin.

Si la demande est :

qui a eu la meilleur note ?

quel est l'intérêt de faire une jointure externe ?

[SQLpro]

"Les cons, ça ose tout... C'est même à ça qu'on les reconnait !"
Michel Audiard

" - le crétin chimiquement pur, vous le trouvez ou ?
- chez developpez.net, je suis fidèle à mes fournisseurs !"
Michel Audiard, adpation Fred Brouard...

Bref, les mots me manque pour dire la stupidité des propos que l'on trouve dans certains forums...

A +

[Waldar]

Je suis d'accord avec SQLPro mais je vais le dire autrement.

Vous avez bien voulu apprendre C++, VB.NET, PHP, mais vous n'avez pas voulu apprendre le SQL ?
C'est parce que c'est syntaxiquement cent fois plus simple que vous préférez au final coder n'importe comment ?

Au final des gens comme vous ça donne du boulot, mais si votre client / employeur lisait ça - et en comprenait les aboutissants - il se passerait très vite de vos services.

[SQLpro]

Je vais rajouter une dernière citation d'Audiard...

"J'ai fait la guerre de 14-18, j'ai été militant communiste et maintenant je suis bistrotier... C'est dire si des conneries j'en ais entendu dans ma vie... Mais des comme ça, jamais !"

A +

[randriano]

Merci à tous d'avoir prêté attention à ce débat car c'en est une
C'est un choix de développement de la boîte où je bosse!

C'est vrai qu'on rencontrera un soucis avec des tables de plus de 100000 lignes, là c'est un cas de force majeure donc on utilise de l'INNER JOIN.

JOIN est une opération d'algèbre relationnelle, nous voulons tous les éléments même ceux égal à zéro

[CinePhil]

Soit le morceau de MCD suivant :
Salarie -1,1----Affecter----1,n- Service

Il engendrera l'exemple de tables suivant :
Service (svc_id, svc_nom)
Salarie (slr_id, slr_id_service, slr_matricule, slr_nom, slr_prenom...)

Tu es bien d'accord avec le fait que slr_id_service ne sera jamais NULL, conformément aux règles imposées par le MCD ?

A quel service est affecté chaque employé ?

Code :

1
2
3
4
5
SELECT slr.slr_matricule, slr.slr_nom, slr.slr_prenom, 
  svc.svc_nom AS nom_service
FROM Salarie slr
INNER JOIN Service svc ON svc.svc_id = slr.slr_id_service
ORDER BY slr.slr_nom, slr.slr_prenom

Quel serait l'intérêt de faire une jointure externe ?

Et des cas comme ça il y en a à la pelle !
Je dirais même que ma petite expérience personnelle me laisse à penser que les jointures externes sont moins fréquentes que les jointures internes.

Alors quand je lis tes messages de cette file, et notamment cette dernière phrase :

C'est un choix de développement de la boîte où je bosse!

Tu as raison de ne pas dire où tu bosses parce que ça ne me donne pas confiance en ta boîte !

Il n'y a que très rarement des cas de force majeure ! Il y a des règles de gestion des données et des besoins exprimés.

Si je veux la liste des véhicules et leur affectation, même ceux qui ne sont pas affectés, je fais une jointure externe.
Si je veux la liste de tous les chauffeurs actifs et le véhicule qui leur est affecté, je fais une jointure interne.

On t'a démontré plus haut que le fait de ramener toutes les lignes pouvait fausser un résultat (la moyenne de aieeeuuuuu). Si malgré tout ce qu'on t'a dit tu persistes dans la pensée exprimée par le titre de la file de discussion que tu as créée, c'est peut-être que tu entre dans une des catégories exprimées un peu sèchement mais avec humour par SQLPro !

[randriano]

Envoyé par CinePhil

Tu es bien d'accord avec le fait que slr_id_service ne sera jamais NULL, conformément aux règles imposées par le MCD ?

..............................

Je dirais même que ma petite expérience personnelle me laisse à penser que les jointures externes sont moins fréquentes que les jointures internes.

oui je le suis

Jointure externe moins fréquente!!!??

Il n'y a que très rarement des cas de force majeure ! Il y a des règles de gestion des données et des besoins exprimés.

Si je veux la liste des véhicules et leur affectation, même ceux qui ne sont pas affectés, je fais une jointure externe.
Si je veux la liste de tous les chauffeurs actifs et le véhicule qui leur est affecté, je fais une jointure interne.

Exemple convaincant mais en développant des sites web institutionnels et autres, il semble qu'on a rarement rencontré le cas n°2

[Erwy]

Envoyé par CinePhil

Je dirais même que ma petite expérience personnelle me laisse à penser que les jointures externes sont moins fréquentes que les jointures internes.

La mienne te rejoint, et pourtant je travaille sur un modèle de donnée ou elle est parfois obligatoire.
Mais pour 1 jointure externe j'utilise au moins 10 jointures internes.

Envoyé par randriano

Exemple convaincant mais en développant des sites web institutionnels et autres, il semble qu'on a rarement rencontré le cas n°2

C'est quoi un site institutionnel ???
Je travaille sur des sites gouvernementaux avec des données Européennes , dans le genre institutions...


Je rejoins les autres et rajoute que pour sortir des trucs comme ça faut avoir complétement foiré la modélisation de sa base

[fsmrel]

Envoyé par Erwy

pour sortir des trucs comme ça faut avoir complétement foiré la modélisation de sa base

Bien résumé. Professionalisme => modèles conceptuels de données (ou diagrammes de classes) bien dépliés, c'est-à-dire absence de cardinalités 0,1, donc absence au niveau logique de clés étrangères polluées par le bonhomme NULL, et par contrecoup éliminination dans les requêtes des jointures externes inhérentes.

Envoyé par randriano

JOIN est une opération d'algèbre relationnelle

Exact, c’est ce que confirme la référence The Relational Database Dictionary. Mais vous n’y trouverez rien sur la jointure externe qui est exclue de l’algèbre relationnelle.

[randriano]

Wow, je subis la foudre des développeurs sur ce sujet, tout le monde vote contre mes messages! En effet, l'irritant de ce fil c'est sûrement mon expression: CAS DE FORCE MAJEURE???

C'est bien, j'adore car ça peut aider.

Avoir foiré totalement la modélisation des données, je ne pense pas, je tiens à remarquer qu'avec des applications lourdes (pour machine: dotnet, c++, windev), on utilise essentiellement de la jointure interne car on y travaille avec une grande base de données.