Est-ce que l'ordre des expressions ou prédicats faire une différence dans la condition de jointure pour les jointures externes dans la norme SQL?

voix
2

Donc, je vais avoir un peu d'une journée frustrante. Je suis tiré d'un contrat, je travaillais depuis quelques semaines parce que je ne l'ai pas « maillage avec l'équipe. » Deux exemples ont été cités:

1) Hier , on m'a demandé de supprimer toutes les données d'une base de données SQL Server , sauf pour certaines données du système de base. Le demandeur (pas mon patron) avait environ huit scripts qu'elle avait utilisés pour cette tâche il y a quelques mois. Apparemment , personne n'a jamais pensé à scripter le modèle de données ou les données du système.

Cette personne avait établi un modèle de trop compliquer les choses, alors je tentais de comprendre les raisons de la tâche et l'objectif final. Je luttais aussi de comprendre pourquoi elle a toujours eu toutes sortes d'erreurs vagues qui exigeaient tous ces scripts supplémentaires pour « supprimer et ajouter des contraintes ».

J'étais tout à fait prêt à tout nécessaire et nous avons parlé pendant plusieurs minutes à ce sujet. Pour des raisons évidentes, je pensais que chercher à comprendre pourquoi était une bonne chose. Tout à coup, elle a décidé que ce serait tout simplement plus rapide de le faire elle-même plutôt que de passer du temps à expliquer tout cela pour moi et je suis retourné à mon autre travail sans y penser plus.

D'une certaine manière cela a été négativement interprété.

2) Il y a plusieurs semaines au cours de ma première semaine , on m'a demandé de travailler sur la fusion des données d'un autre système. On m'a donné un script de ligne 600+ d'extraits de SQL que tout semblait être importante avec une tirade orale des plaintes au sujet des données pauvres et les programmeurs d' origine. Naturellement , il a fallu un peu de temps à patauger dans de près , mais après quelques jours , mon résultat final a émergé comme une simple fusion dans environ 25 lignes.

J'ai écrit SQL depuis plus de dix ans et je me considère d'avoir une certaine expertise dans le domaine. Mes collègues devenaient un peu impatient que j'épluché les couches de complexité inutile et je suis resté tard pour terminer la tâche comme promis.

Je ne savais pas comment ils accepteraient facilement que la solution du problème semble être exactement une commande très courte et je me demandais si je manque quelque chose qui se révélera être gênant. Malheureusement, toutes mes questions pénétrantes avaient été satisfaites à plusieurs reprises avec le genre de non-réponses méprisantes que les enseignants pauvres donnent à un étudiant élémentaire trop curieux. J'ai donc envoyé la requête ainsi que dans un e-mail et suis rentré chez moi.

Le lendemain matin, on m'a dit (même personne que # 1) qu'il était mal mais c'était des choses que je ne pouvais pas être censé savoir que le nouveau type. Elle a expliqué qu'elle devait se retenir de réécrire tout. L'un de ses points de était quelque chose de mineur sur les données que j'avais déjà l'intention de lui poser des questions sur moi-même. L'autre était purement SQL.

(La question commence ici.)

Prenez un scénario typique externe gauche se joindre. Nous savons tous que l'ordre des tables est assez importante, par exemple, Q1 et Q2 ne sont pas équivalents:

SELECT A.x, B.y FROM A LEFT OUTER JOIN B ON A.id = B.id -- (Q1)
SELECT A.x, B.y FROM B LEFT OUTER JOIN A ON B.id = A.id -- (Q2)

Quand je pense conceptuellement sur la sclérose me semble généralement naturel se joint à imaginer ramasser la nouvelle table comme l'objet d'intérêt et décrivant la façon dont ses lignes sont liées à ce qui est venu avant. Garder les termes en parallèle n'a pas d'avantage pour moi et par moi-même l'habitude j'écris généralement la condition de jointure de cette façon:

SELECT A.x, B.y FROM A LEFT OUTER JOIN B ON B.id = A.id -- (Q3)

Je me trouve donc suivaient des cours sur la façon dont l'ordre des questions tables dans une jointure externe. Je pensais que ce test de mon intelligence a déjà été fait au cours de l'entretien d'embauche. Ma confusion transformé en stupeur que je réalisais qu'elle se concentrait uniquement sur la comparaison de l' égalité. Pour son 3ème trimestre a eu tort et Q1 est la version que je avais besoin à la place.

Je diplomatiquement insisté qu'il n'a pas fait aucune différence et que je pouvais facilement prouver mon cas, si elle voulait. J'ai essayé de clarifier son raisonnement mais c'est le genre de personne qui ne l'écoute pas étroitement à vos questions, peu importe la façon dont ils sont soigneusement formulés ou combien de mots techniques que vous utilisez pour suggérer un petit niveau de compétence, alors j'ai décidé que je viens n'a pas pu la convaincre que je ne suis pas un idiot. Et j'ai accepté de changer le script parce qu'il ne valait pas argumenter au sujet.

Je suppose que ne pas avaler tout de suite ma fierté a démontré que je n'étais pas « coachable. »


Pour ce qui est seul le style, je me conforme à une norme que l'employeur préfère que leur SQL est souvent bâclée dans d'autres façons. Je reconnais que, avec l'ancien style jointure externe syntaxe ce serait la matière. Au-delà, je ne l'ai jamais entendu quelqu'un faire ce cas. S'il vous plaît répondre à cette question et d'échanger ma réputation.

Est-ce que l'ordre des expressions ou prédicats faire une différence dans la condition de jointure pour les jointures externes dans la norme SQL?

Créé 07/07/2012 à 01:54
utilisateur
Dans d'autres langues...                            


4 réponses

voix
2

L'ordre de la comparaison de l'égalité ne fait aucune différence pour les résultats de la jointure. Mais il pourrait, pour des raisons insondables affecter l'efficacité avec laquelle le résultat est calculé. optimiseurs SQL sont connus pour être affectés par des détails apparemment sans importance comme celui-ci.

Créé 07/07/2012 à 02:04
source utilisateur

voix
4

Non, il ne fait aucune différence.

Personnellement , je préfère le style que vous montrer au 3e trimestre, certains de mes collègues préfèrent le style au 1er trimestre. Je ne connais personne qui jamais considérer l' un d'eux d'être mauvais .

L'Optimiseur de requête tourne la requête intérieur en quelque chose de complètement différent, de sorte que le prédicat n'existe même pas comme une comparaison plus simple quand il est fait avec elle. Habituellement, il est une recherche dans un index ou une table, et que cela ne peut se faire dans un sens, la façon dont le prédicat a été écrit ne fait aucune différence.

J'ai vérifié (dans SQL Server 2005) le plan d'exécution de deux requêtes avec les opérandes sous-jacentes dans un ordre différent, et comme prévu, ils sont identiques.

Créé 07/07/2012 à 02:21
source utilisateur

voix
2

Je préfère Q3 rejoignons aussi de l'ordre de l'état:

... ON B.id = A.id -- (Q3)

Comme il reflète directement que le B.id est plus ou moins un, vous pouvez penser à A.id comme l'être constant testé contre, par exemple,

B.id = 1984

Dans la même veine que je ne veux pas voir dans le code ...

1984 = B.id

..., comme vous, je ne veux pas voir cela dans la requête:

A.id = B.id

Cependant, comme la plupart des choses dans la vie, il y a des gens qui aiment peu endian, et il y a ceux qui aiment big-endian. Quel que soit le modèle mental, il peut les servir sur la préférence qu'ils ont choisi, ils devraient être au moins en mesure de vous expliquer les raisons pour lesquelles ils ont vouluA.id = B.id

Je pense, je dois changer ma préférence bien, mon (et votre) afin de l'état préféré ne fonctionne pas dans certains ORM, Linq en particulier. Je n'ai pas encore saisir pourquoi ils imposent que la condition doit être dans l'ordre Q1:

from x in A
join y in B on x.id equals y.id

Et inverser la condition (comme Q3, bien que dans la requête SQL est pas une erreur) Résultats de la commande à erreur de syntaxe, ce ne sera pas acceptée par Linq:

from x in A
join y in B on y.id equals x.id

Maintenant, je dois trouver la raison pour laquelle les concepteurs Microsoft Linq ont préféré l'ordre de l'état Q1. Et essayer d'apprécier si elle est logique, et juste accepter même ne pas (encore) est logique.


En ce qui concerne:

Est-ce que l'ordre des expressions ou prédicats faire une différence dans la condition de jointure pour les jointures externes dans la norme SQL?

Les résultats sages, NO . Côté performance, je dois encore voir une requête où la requête fait plus rapidement l'ordre de l' état de la jointure. Même dans les forums , je ne l' ai pas vu quelqu'un approuve inverser la condition pour accélérer la requête.

S'ils ne peuvent pas vous expliquer la raison d'être ou le modèle mental de leur ordre de condition préférée est bonne, peut - être qu'ils ne font que la programmation Cargo Cult ou pire encore, Bikeshedding

Créé 07/07/2012 à 02:48
source utilisateur

voix
1

Je préfère votre Q1, mais il fait absolument aucune différence dans la performance et n'a absolument aucun effet sur l'optimiseur de requêtes.

Pour moi, mettre la table précédente me donne d' abord les informations pertinentes plus tôt dans mon processus de numérisation. Je peux lire join table B on A ...et de savoir déjà que deux tables sont reliées entre elles. Quand je lis que join table B on B.blasdjasdid = ...j'ai dû analyser beaucoup plus loin et ne sais toujours pas les informations les plus importantes, qui table est reliée à ( ce qui est une sorte d'espace de noms, un domaine dans lequel le nom de la colonne sera comprise). De plus, si les colonnes portent le même nom dans les deux tables (idiomatiques dans une base de données que je conception), je peux éviter le balayage à la fin tout à fait , la lecture seule join table B on A.SomethingId ...et sachant déjà que c'est = B.SomethingId.

Pour aller un peu plus loin, je vous encourage à poser des questions sur cet événement sur workplace.stackexchange.com parce que je pense que les raisons de vos services ont été abandonnées ne correspondent pas à ce qu'ils vous ont dit; une enquête sur ce qui pourrait être productive. Je ne suggère pas que c'était votre faute, mais que la raison donnée était probablement un prétexte.

Créé 29/12/2015 à 19:14
source utilisateur

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more