Discussion :

[nuke_y]

Tu m'as convaincu des possibilités d'un SGBD plus proche de la théorie mathématique et je pense en effet que s'il avait un distinct automatique géré par le système (ou le language SQL) depuis le début, ça ne nous choquerait pas. Il faudrait juste ramener le nombre de filles en plus (ou leurs noms) si on veut savoir combien il y en a.

Maintenant ce genre de phrase est une sérieuse incitation au troll :

Code :

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

Maintenant, j'étais informaticien quand vous n'étiez pas nés

ça serait dommage que ce sujet termine cloturé.

[orafrance]

sans récupérer des doublons, sans avoir à rajouter un DISTINCT ou autre artifice et qu'il est à la charge du langage et non pas à votre charge d'éliminer les doublons : le but est que le comportement du SGBD reste prévisible, stable et que ce ne soit pas à vous de pallier les lacunes de SQL. C’est le B-A BA de l’algèbre relationnelle que vous utilisez. Si SQL avait été conçu correctement dès le départ, vous n’y verriez aujourd’hui aucun inconvénient, au contraire...

j'ai l'impression que tu voudrais que le SGBD se substitue à l'analyse fonctionnelle

Comment développer un SGBD qui sait dédoublonner quand on a nous même du mal à le faire parfois ? Si on veut chippoter on peut même dire qu'Oracle assure la distinction des lignes... grâce au ROWID

En tout cas, dans une table du personnel je ne vois pas comment le SGBD peut décider de dédoublonner sur la date de création, l'id ou le salaire

nuke_y en effet, l'ancienneté dans le métier est loin d'être un gage de professionnalisme, alors tenons nous en aux faits et faisons en sorte que ce débat reste serein SVP.

[remi4444]

@fsmrel :



J’ai l’impression que je me suis mal fais comprendre, alors je recommence…

Pour moi, ils n’y a pas d’anomalie mathématique dans le fonctionnement des jointures puisque lorsqu’on affiche toutes les colonnes identifiantes de toutes les tables jointes, on vérifie toujours qu’il n’y a pas de doublon. Ensuite, le choix d’afficher une colonne ou pas (ce qu’il y a entre le SELECT et le FROM) n’est plus du domaine de la recherche mais de la mise en forme. C’est en ça aussi que le distinct est malsain, parce qu’il fait dépendre le nombre de lignes ramenées du choix des colonnes affichées, et même pire : du contenu. Son utilisation est une bombe à retardement et je l’ai vérifié à plusieurs reprises (et oui, moi aussi j’ai une petite expérience ). Si le dédoublonnage était implicite, alors il y aurait une grande instabilité. C’est là que nos avis divergent.
Pour moi le distinct est lui aussi classé dans les instructions de mise en forme. Si j’avais un reproche à faire au langage SQL, ce n’est pas d’autoriser l’affichage de doublon, c’est plutôt d’autoriser l’utilisation du DISTINCT ! Si on a un modèle pur, c’est à dire que chaque information est bien référencée de manière unique quelque part, alors on peut toujours se passer de cette clause. Si le distinct n’existait pas, ça obligerait les développeurs à utiliser les bonnes instructions au bon moment, en particulier utiliser les instructions de filtrage (EXISTS) pour le filtrage.

Dans l’exemple de nuke_y :

Code :

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

1
2
3
4
SELECT   D.Nom
FROM     Developpeur D, SGBD S 
WHERE    D.Dev_Id = S.Dev_Id
   AND   S.Nom = ‘Oracle’ ;

Si l’intention était de ramener la liste des développeurs oracle, alors ce n’est pas la bonne syntaxe qui est employée c’est tout. On ne peut tout de même pas demander à un langage d’aller lire dans les pensées confuses du développeur et corriger de lui-même toutes les erreurs de ce dernier…

J’ai l’impression que dans votre esprit, il faudrait que le langage sql considère que toute table dont on n’affiche aucune colonne bascule automatiquement dans du filtrage (ie : un EXISTS automatique conditionné par le choix des colonnes du select ). Personnellement, ça ne me plait que moyennement parce que je n’aime pas que les outils informatiques prennent trop d’initiative, mais c’est mon opinion personnele…

Ensuite, que le langage sql comme la plupart des autres permette de faire tout et n’importe quoi, on est d’accord. Que des conceptions bâclées et des informaticiens mal formés, conduisent des projets à la catastrophe, on est d’accord aussi mais c’est un autre débat, qui ne concerne pas que l’informatique d’ailleurs…

[fsmrel]

Tu m'as convaincu des possibilités d'un SGBD plus proche de la théorie mathématique et je pense en effet que s'il avait un distinct automatique géré par le système (ou le language SQL) depuis le début, ça ne nous choquerait pas. Il faudrait juste ramener le nombre de filles en plus (ou leurs noms) si on veut savoir combien il y en a.

Bien raisonné. Pour sa part, l’opérateur d’agrégation COUNT fait partie à juste titre des opérateurs des langages relationnels, il est tout à fait respectable. Il permet justement de compter car cela est pour le moins légitime.

Pour moi, ils n’y a pas d’anomalie mathématique dans le fonctionnement des jointures puisque lorsqu’on affiche toutes les colonnes identifiantes de toutes les tables jointes, on vérifie toujours qu’il n’y a pas de doublon.

Il n’y a effectivement pas d’anomalie mathématique concernant la jointure en tant que telle puisque par définition elle est une restriction appliquée à un produit cartésien (ces deux opérateurs étant des primitives de l’algèbre relationnelle). Pour en venir au cas particulier des colonnes identifiantes, que le résultat ne comporte pas de doublons quand on affiche toutes ces colonnes, vous avez raison, c’est vrai, par construction. Maintenant, Ted Codd n’a pas inventé la jointure pour traiter du cas particulier mais du cas général.

En vertu de quoi, je ne me lasserai donc pas de répéter qu’au nom de la fermeture, le résultat de la jointure de deux tables doit être une table et pas autre chose (tel qu’un sac). Pour parler de façon imagée, la jointure de deux tables c’est comme l’union d’un homme et d’une femme : le fruit de leur mariage doit être de même nature que ses parents et pas autre chose.

En passant, personne n’a l’air choqué que le résultat de l’opérateur UNION ne comporte pas de doublons (SQL est conforme en l’occurrence).

le choix d’afficher une colonne ou pas (ce qu’il y a entre le SELECT et le FROM) n’est plus du domaine de la recherche mais de la mise en forme.

C’est évident. Une fois que l’on a obtenu le résultat, on le présente mis en forme à l’utilisateur final qui joue le rôle de maître d’ouvrage alors que nous ne sommes que des maîtres d’œuvre (ce qui engage notre responsabilité au niveau de la recherche). Maintenant, cet utilisateur peut se poser des questions et se résigner en constatant qu’on lui présente des doublons tout en se disant que le développeur a sans doute ses raisons que lui, utilisateur, ignore. Attention si de votre résultat vous faites une vue (donc manipulable comme une table) ou si vous l’exportez dans un fichier à destination d’une autre application (un utilisateur final peut aussi être un programme), on repart pour des requêtes qui doivent donner des résultats valides.

Je rappelle au passage que, pour ne pas en rester au cas particulier de la présentation d’un résultat, il ne faut pas oublier que l’occasion peut se présenter de faire participer ce résultat à un FROM en tant qu’expression de table : peut-être aurez vous alors à modifier le SELECT pour que les résultats soient valides...

En passant merci à Hugh Darwen qui, il y a une bonne quinzaine d’années, a su convaincre ses collègues du comité du standard SQL pour que nous puissions inclure des expressions de tables dans un FROM : son argument décisif fut l’application du principe de fermeture.

C’est en ça aussi que le distinct est malsain, parce qu’il fait dépendre le nombre de lignes ramenées du choix des colonnes affichées, et même pire : du contenu. Son utilisation est une bombe à retardement et je l’ai vérifié à plusieurs reprises (et oui, moi aussi j’ai une petite expérience).

On est en phase.

Si le dédoublonnage était implicite, alors il y aurait une grande instabilité. C’est là que nos avis divergent.

De fait, on n’est plus en phase. Éliminer les doublons par projection ou autre opération relationnelle entraîne stabilité. En effet, au lieu de s’attendre à un nombre aléatoire de lignes en double au fil de l’exécution d’une requête donnée, on sait d’avance que le système ne produit qu’un exemplaire unique de ces lignes, ce qui revêt un caractère rassurant d’invariance, de stabilité dans le comportement. Pensez encore à l’opérateur UNION qui ne produit pas de doublons : qui s’en offusque ? Pensez aussi une fois de plus à l’exemple de l’ensemble des entiers naturels, dans lequel le nombre 1 n’existe qu’à un seul exemplaire et non pas à un nombre variable d’exemplaires en fonction par exemple de l’emboîtement des opérations arithmétiques et de l’âge du capitaine. L’arithmétique de bégaie pas, même chose pour le Modèle relationnel.

Pour moi le distinct est lui aussi classé dans les instructions de mise en forme

Pour vous oui, mais pas pour ceux qui font SQL, c’est bien là le problème.

Si on a un modèle pur, c’est à dire que chaque information est bien référencée de manière unique quelque part, alors on peut toujours se passer de cette clause.

Même avec le modèle le plus pur qui soit, à un moment donné vous êtes amené à effectuer des projections/restrictions auxquelles ne participent pas les clés primaires (ou plus généralement candidates). Par exemple si on interroge la table des développeurs :

"Dans quelles villes trouve-t-on des spécialistes d’Oracle ?" :

alors inutile d’apprendre mille fois que Paris répond à la question, une fois suffit. Méditez ce qu’écrivait Guillaume d’Ockham il y a près de 700 ans : "Ne multipliez pas les entités au-delà du nécessaire".

Si le distinct n’existait pas, ça obligerait les développeurs à utiliser les bonnes instructions au bon moment, en particulier utiliser les instructions de filtrage (EXISTS) pour le filtrage.

Si SQL était relationnel et évacuait les doublons en appliquant correctement la projection, la jointure suffirait, sans recours à EXISTS et DISTINCT. EXISTS ne fait pas partie de l’algèbre relationnelle, contrairement à la jointure et à la projection (la quantification existentielle fait partie du calcul relationnel, mais ceci est une autre histoire). L’algèbre relationnelle est complète (permet de produire tous les résultats possibles) sans ajouter des rustines telles que EXISTS (ou DISTINCT...) Je rappelle que (NOT) EXISTS a été ajouté à SQL pour pallier l’absence initiale de l’opérateur ensembliste MINUS (rebaptisé EXCEPT dans certains dialectes) indispensable pour qu’un langage relationnel soit complet.

J’ai l’impression que dans votre esprit, il faudrait que le langage sql considère que toute table dont on n’affiche aucune colonne bascule automatiquement dans du filtrage (ie : un EXISTS automatique conditionné par le choix des colonnes du select ). Personnellement, ça ne me plait que moyennement parce que je n’aime pas que les outils informatiques prennent trop d’initiative, mais c’est mon opinion personnele…

C’est dans mon esprit, mais ce le fut surtout dans celui de Ted Codd, père du Modèle relationnel (modèle dont SQL se réclame, tout en oubliant d’en appliquer les règles) : éliminer les doublons pour rester dans la théorie des ensembles. Par ailleurs, Le Modèle relationnel n’est pas un outil informatique mais une branche des mathématiques appliquées : nuance ! Je répète ce que je viens de dire : comme SQL n’applique pas correctement la projection, la restriction et la jointure, c’est vous qui en pâtissez en devant jongler avec les rustines ad-hoc DISTINCT, EXISTS et compagnie.

j'ai l'impression que tu voudrais que le SGBD se substitue à l'analyse fonctionnelle

Celle-là je ne la connaissais pas...
Certes non ! Une analyse fonctionnelle correcte a pour objet (entre autres) de traiter du quoi :

Décrire la structure des données, les règles de gestion de ces données (et les contraintes) ainsi que les traitements à effectuer et cela le SGBD ne peut pas le faire à la place de l’analyste. Maintenant, que l’on intègre un maximum de quoi dans quelques lignes de requêtes, plutôt que de développer à cet effet des programmes de quelques centaines de lignes en C, en Pascal, en Cobol ou que sais-je, voilà une "substitution" raisonnable.

On sous-traite au SGBD le comment. Notamment en lui précisant de manière déclarative ce qu’il a à faire (via les requêtes SQL, dans lesquelles nous exprimons ce fameux quoi, encore et toujours). Sous le capot, l’optimiseur s’agite pour trouver comment opérer avec la meilleure stratégie. Au point que si vous voulez vérifier qu’il ne déraille pas, vous savez très bien que vous devez en passer par un EXPLAIN, avant et après collecte des statistiques, etc. pour détecter les grands balayages de tables au détriment des index et autres turbos.

Comment développer un SGBD qui sait dédoublonner quand on a nous même du mal à le faire parfois ?
En tout cas, dans une table du personnel je ne vois pas comment le SGBD peut décider de dédoublonner sur la date de création, l'id ou le salaire

Surprenant à nouveau.
L’objet est simple : une opération relationnelle (restriction, projection, jointure, union, etc.) a des tables comme opérandes et le résultat doit être une table et pas un sac. C’est une règle d’or, portant le nom de fermeture (règle déjà évoquée). Prenez PRTV ou Tutorial D : ils respectent cette règle sans aucune difficulté parce qu’ils ont été conçus dans le strict respect du Modèle relationnel. Considérez le cas de la projection : quand vous écrivez

SELECT col1, col2,..., coln

vous projetez sur col1, col2,..., coln. Un SGBD qui adhère à la théorie relationnelle se contente d’éliminer les doublons du résultat sans se poser de questions. Je ne vois pas ce qu’il y a de compliqué. A vous de déterminer le quoi, quelles colonnes (date de création, id, salaire) participent à la projection. Laissez le comment au SGBD. Maintenant si SQL bégaie (j’ai bien dit SQL, le Sorry Query Language), à vous d’utiliser les rustines qui permettent d’apurer le résultat de votre SELECT.

Si on veut chippoter on peut même dire qu'Oracle assure la distinction des lignes... grâce au ROWID

Le Rowid peut être jugé pratique, mais c’est encore quelque chose qui n’a rien à voir avec le Modèle relationnel et qui en plus vous rend dépendant de votre SGBD. Ça n’est jamais qu’un pointeur du genre de ceux que qu’on utilisait avec les SGBD pré-relationnels et dont on peut vraiment se passer quand on raisonne relationnel. Avec le Rowid, l’intégrité conceptuelle est violée. Ted Codd n’a cessé de répéter :

Toute l’information contenue dans une base de données relationnelle est représentée explicitement au niveau logique d’une façon unique – par des valeurs dans des tables.

Ce qui disqualifie les pointeurs. A noter accessoirement qu'en respectant cette règle, on peut aussi exporter ses bases de données et ses requêtes.

l'ancienneté dans le métier est loin d'être un gage de professionnalisme

Et toc, une affirmation gratuite bien peu courtoise et aussi constructive que les remarques précédentes du responsable SGBD. Je suis donc manifestement visé. Sachez que Ted Codd, Chris Date et Hugh Darwen m’ont reconnu pour un des leurs et leur jugement a plus de valeur pour moi que tout autre. Même chose concernant les universitaires avec lesquels j’ai collaboré avec profit. Même chose concernant tous ceux pour qui je me suis dépensé, sans compter les heures, pour que leurs bases de données fonctionnent enfin, et bien. Le jugement subjectif et gratuit porté par quelqu’un que je ne connais pas, qui ne me connaît pas et surtout qui ne connaît manifestement rien à la théorie relationnelle (et n’a strictement rien apporté à la discussion) me laisse parfaitement indifférent. Maintenant, si vous êtes capable d’apporter la preuve de mon amateurisme, je suis preneur car toujours prêt à progresser. Je préviendrai à l’occasion ceux que je viens de citer, ça pourrait les intéresser que vous leur apportiez quelque chose...

tenons nous en aux faits et faisons en sorte que ce débat reste serein SVP.

Après ce que vous venez de dire, voilà une magnifique preuve de tartufferie. Le débat avait été serein et vous voudriez qu'il ne le reste pas : no comment. Je vous laisse à vos faits.

Merci en tout cas à ProjetM, nuke_y et remi4444 d’avoir cherché à être constructifs.

[nuke_y]

Très très intéressant tout ça. J'espère me rappeler de cette conversation le jour où je travaillerais sur le premier SGDB relationnel respectueux de la théorie mathématique.

J'en encore un peu de mal entre "table" et "sac" :

table = ensemble de données organisé en lignes et colonnes et dont chaque ligne est unique (soit possède au moins une colonne de différente par rapport aux autres lignes)

sac = ensemble de données organisé en lignes et colonnes et dont les lignes ne sont pas forcément uniques (donc deux lignes peuvent avoir exactement les mêmes valeurs pour toutes leurs colonnes. Le "doublon" quoi).

Ceci est particulièrement intéressant :

quand vous écrivez SELECT col1, col2,..., coln vous projetez sur col1, col2,..., coln.

Je comprend mieux effectivement si on parle de projection sur des axes de dimensions qui sont chacun des ensembles de valeurs. Effectivement, sur chaque axe n'existe qu'une seule valeur.

Par contre je n'ai pas vraiment compris le principe de fermeture... ça veut dire qu'il faut (faudrait) que l'opération de deux éléments de type "table (cf définition ci dessus) via un opérateur SQL soit de type "table" ? Ca resterait logique, effectivement, et ça me rappelerait beaucoup les mathématiques des ensembles, groupes, anneaux etc.


Par contre, sans vouloir ramener le débat au niveau des paquerettes, ici on est dans la rubrique Oracle. On essaye d'arriver à faire fonctionner cette grosse bêbête et on s'échange des astuces pour arriver à la convaincre de faire ce qu'on veut. Je me demande si un débat comme celui-là, bien que très intéressant, n'aurait pas plus sa place dans général SGDB (déjà rien que parce que ça intéresserait sûrement d'autres visiteurs que ceux qui se limitent à la section Oracle). Et en plus il y a sûrement plus de théoriciens dans cette section qu'ici

[orafrance]

Éliminer les doublons par projection ou autre opération relationnelle entraîne stabilité. En effet, au lieu de s’attendre à un nombre aléatoire de lignes en double au fil de l’exécution d’une requête donnée, on sait d’avance que le système ne produit qu’un exemplaire unique de ces lignes, ce qui revêt un caractère rassurant d’invariance, de stabilité dans le comportement. Pensez encore à l’opérateur UNION qui ne produit pas de doublons : qui s’en offusque ?

Mais alors que fais tu du UNION ALL ? Tu serais donc en train d'affirmer que l'UNION ALL est inutile ? Pour moi, un UNION ALL qui retourne deux lignes identiques c'est soit une erreur de conception (2 lignes identiques dans deux tables différentes) soit un besoin fonctionnel (table parent + table enfant, un enfant peut être un parent et je ne veux pas perdre l'information).

Pensez aussi une fois de plus à l’exemple de l’ensemble des entiers naturels, dans lequel le nombre 1 n’existe qu’à un seul exemplaire et non pas à un nombre variable d’exemplaires en fonction par exemple de l’emboîtement des opérations arithmétiques et de l’âge du capitaine. L’arithmétique de bégaie pas, même chose pour le Modèle relationnel.

Je ne comprends pas bien l'intérêt de comparer l'arithmétique et les ensembles Dans ce cas, on peut surment s'intéresser aux dérivés et intégrales qui produisent des résultats surprenants. Ta comparaison est aussi hasardeuse que si j'affirmais qu'un carré ne peut être négatif et que je sortais l'exemple de l'irréel

Pour vous oui, mais pas pour ceux qui font SQL, c’est bien là le problème.

mais pas du tout, le DISTINCT fait parti des opérateurs de la norme ANSI92 sans aucune ambiguité. Je t'invite à lire les articles sur http://sql.developpez.com dont Frédéric Brouard est à l'origine. Si tu es un spécialiste du SQL tu le connais surement

"Dans quelles villes trouve-t-on des spécialistes d’Oracle ?" :

alors inutile d’apprendre mille fois que Paris répond à la question, une fois suffit. Méditez ce qu’écrivait Guillaume d’Ockham il y a près de 700 ans : "Ne multipliez pas les entités au-delà du nécessaire".

Sauf si en plus j'ajoute l'information sur le nom de ces spécialistes. Si je ne veux pas voir Paris plusieurs fois, c'est la que l'aggrégation intervient... il est évident que si tout était unique les SUM n'existerait pas... sommer une ligne seule n'a aucun sens (ou alors je n'ai pas compris ta démonstration ce qui n'est pas impossible )

L’algèbre relationnelle est complète (permet de produire tous les résultats possibles) sans ajouter des rustines telles que EXISTS (ou DISTINCT...) Je rappelle que (NOT) EXISTS a été ajouté à SQL pour pallier l’absence initiale de l’opérateur ensembliste MINUS (rebaptisé INTERSECT dans certains dialectes) indispensable pour qu’un langage relationnel soit complet.

Je suis navré mais tu parles de facilités techniques qui remplacent des opérations sur les ensembles. Le MINUS est d'ailleurs une catastrophe, heureusement que les SGBD ont mis en oeuvre le EXISTS. C'est un exemple parfait pour montrer que ce qui marche sur le papier ne marche pas forcément quand on le met en oeuvre. C'est toute la différence entre un algo et son programme . En revanche, je ne savais pas que MINUS était absent des SGBD et ça me laisse même perplexe puisqu'en ce qui concerne Oracle ça existe depuis la V6 (autant dire un autre temps )

C’est dans mon esprit, mais ce le fut surtout dans celui de Ted Codd, père du Modèle relationnel (modèle dont SQL se réclame, tout en oubliant d’en appliquer les règles) : éliminer les doublons pour rester dans la théorie des ensembles. Par ailleurs, Le Modèle relationnel n’est pas un outil informatique mais une branche des mathématiques appliquées : nuance ! Je répète ce que je viens de dire : comme SQL n’applique pas correctement la projection, la restriction et la jointure, c’est vous qui en pâtissez en devant jongler avec les rustines ad-hoc DISTINCT, EXISTS et compagnie.

Mais si les SGBD ne s'adaptaient pas aux besoins de la "vraie" vie on ne s'en sortirait pas. Je reviens sur le MINUS. Fais donc un MINUS entre deux tables de plusieurs millions de lignes, les indexes ne te seront d'aucun secours et les perfs seront catastrophiques. Alors oui, le SQL Oracle n'est pas le SQL ANSI qui n'est pas non plus des mathématiques au sens strict du terme (d'ailleurs le SQL se réclamerait plutôt de Merise que de Todd Codd ).

Donc comprends donc bien ton point de vue et suis parfaitement d'accord... par contre, contrairement à toi, je salue les évolutions apportées par les SGBD à une science qui ne répond pas au besoin de l'informatique.

Un SGBD qui adhère à la théorie relationnelle se contente d’éliminer les doublons du résultat sans se poser de questions.

OK... alors le SELECT est le suivant :

Code :

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

SELECT dep,nom, salaire FROM employés WHERE dep = 'X'

Et je veux faire une sommes des salaires sur le résultat

Code :

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

1
2
3
SELECT dep, sum(salaire) from (
SELECT dep,nom, salaire FROM employés WHERE dep = 'X'
)

que crois tu qu'il va se passer su Oracle à la bonne idée de ne pas répéter les personnes qui on le même nom et le même salaire ? Et bien la somme sera fausse. Alors là l'exemple est idiot (je te l'accorde ) puisqu'on écrirait pas la requête ainsi. Mais cela illustre le risque que comporterait un SGBD qui ne serait pas exhaustif.

PS : n'oublie pas que tu es dans le forum Oracle et donc que tu t'adresses à des personnes plus pratiques que théoriques

[nuke_y]

Dans un système comme le préfère fsmrel il faudrait faire ça :

Code :

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

SELECT dep, sum(salaire*count(1)) FROM ( SELECT dep,nom, salaire, count(1) FROM employés WHERE dep = 'X' )

Ce qui n'est pas plus contraignant ni moins illogique que de devoir utiliser le distinct pour se débarasser de lignes superflues parfois.

Comme on l'a dit, le système est tel qu'il l'est actuellement et on s'en sert comme on peut. Il serait différent que ça ne nous choquerait sûrement pas plus, mais bon voila...

[orafrance]

j'arrive pas à saisir la raison

Pour moi, la restitution de données doit se faire sans intelligence (comme le soulignait fsmrel le cas de l'UNION est étrange en cela). Si on veut "fusionner" les doublons alors c'est à celui qui lance la requête de le demander explicitement. Rien n'interdit à priori d'insérer x fois la même ligne, dans ce cas pourquoi "interdire" la restitution de tous ces doublons ?

[nuke_y]

Parce qu'il y a une différence de point de vue entre l'information et un modèle mathématique, je pense.

Je parle sans savoir, hein, mais j'imagine que si on a le select et le résultat suivant : liste des employés de différentes sociétés par service.

Code :

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

1
2
3
4
5
6
7
8
SELECT SOCIETE, SERVICE, MATRICULE FROM TABLE
 
SOCIETE SERVICE MATRICULE
A           1           A_001
A           1           A_002
A           2           A_003
B           2           B_001
C           1           C_001

Si on le projete sur une représentation en 3 dimensions que voila :

Dimension SOCIETE : {A,B,C,D}
Dimension SERVICE : {1,2,3,4,5,6}
Dimension MATRICULE : {A_001,A_002,A_003,...,A_nnn, B_001, B_002, ..., B_nnn, C_001, C_002,..., C_nnn, D_001, D_002, ..., D_nnn}

On aura bien 1 point pour chaque ligne du résultat car on a unicité des données. Le résultat est bien une table.

Par contre si on réduit la requete à la liste des sociétés et des services :

Code :

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

1
2
3
4
5
6
7
8
SELECT SOCIETE, SERVICE FROM TABLE
 
SOCIETE SERVICE
A           1
A           1
A           2
B           2
C           1

Si on projete ce résultat sur 2 des 3 axes précédents, on obtient des points qui se superposent (A,1), et ça c'est contraire à la logique du modèle mathématique. Evidemment que nous autres informaticiens ça nous intéresse, car toute information est bonne à prendre. Mais d'un point de vue mathématique c'est illogique.

Enfin s'il le faut j'ai tout faux et je suis à côté de la plaque mais c'est comme ça que je comprend l'explication de fsmrel

[orafrance]

Parce qu'il y a une différence de point de vue entre l'information et un modèle mathématique, je pense.

ça, ça ne fait aucun doute mais si le monde se modéliser par une simple équation ça se saurait ce se que je voulais exprimer en disant que la théorie et la pratique sont bien distinctes même si la 1° sert la 2°

[fsmrel]

Je réponds déjà au message de nuke_id (23 décembre 2006 à 02h18)

table = ensemble de données organisé en lignes et colonnes et dont chaque ligne est unique (soit possède au moins une colonne de différente par rapport aux autres lignes)

De manière informelle, c’est exact. Simplement, il faut raisonner en valeurs. Donc, toujours très informellement :

table = ensemble de données organisé en lignes et colonnes et dont la valeur de chaque ligne est unique (contient au moins une valeur de colonne différente par rapport aux valeurs contenues dans les autres lignes pour la même colonne).

Quant au sac, ce que vous avez écrit et exact.

Exemple : Deux développeurs parisiens distincts, appelés Albert, font de l'Oracle.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
Table Développeur :
(Dev_Id, Nom,    SGBD,   Ville)
   d1    Albert  Oracle  Paris
   d2    Albert  Oracle  Paris

Sac Développeur :
(Dev_Id, Nom,    SGBD,   Ville)
   d1    Albert  Oracle  Paris
   d1    Albert  Oracle  Paris             /* doublon => sac */
   d2    Albert  Oracle  Paris

Par contre je n'ai pas vraiment compris le principe de fermeture... ça veut dire qu'il faut (faudrait) que l'opération de deux éléments de type "table (cf définition ci dessus) via un opérateur SQL soit de type "table" ?

Exact. Le résultat d’une opération portant sur une ou deux tables doit être une table. Exactement comme en arithmétique où la somme de deux entiers naturels est un entier naturel et pas autre chose (en revanche, on sait que les entiers naturels ne sont pas fermés pour la soustraction : 2-3 n’est pas un entier naturel).
Vous imaginez la puissance et la fiabilité offertes par l’Algèbre relationnelle quand on respecte ces principes fondamentaux : ensembles, fermeture, complétude des opérateurs...

Je me demande si un débat comme celui-là, bien que très intéressant, n'aurait pas plus sa place dans général SGDB

Certes. Simplement, je sui tombé sur une discussion portant sur EXISTS, sujet fort intéressant à lui tout seul. Mais vous avez raison, le forum Général SGBD est manifestement plus indiqué, pour ce genre de discussion. C’est la première fois que je participe à une discussion du forum Oracle et j'avoue mon étonnement...

[remi4444]

Je ne comprends pas pourquoi vous dites que EXISTS est une rustine, car pour moi c'est précisément l'opérateur qui permet de faire des projections. Certes, son utilisation est moins spontanée que les jointures simples et c'est pour ça que j'embête tous le monde pour son utilisation. Pour moi le langage SQL tel qu'il est actuellement n'est qu'un outils (je persiste) qui permet de faire à peu près tout et n'importe quoi, et donc de faire des choses complètement éloignées de la rigueur mathématique.

Un sgbd comme oracle permet lui aussi une implémentation de données violant tous les principes qu'on veut... (ex: on n'est meme pas obligé de mettre un clef primaire à une table!)

Mais partir de ça, on peut très bien se donner une discipline aussi bien en implémentation qu'en écriture SQL, et ne s'autoriser qu'a faire des choses conformes aux principes que vous énoncez. Par exemple, lorsqu'on veux faire une projection on utilise EXISTS, lorsqu'on veux des donnée entre 2 entités jointes, on ramène systématiquement les identifiants de chaque entité, on s'assure ainsi d'avoir bien une table comme resultat en restant conforme au principe de fermeture.

Si le puis me permettre et pour caricaturer, votre exemple sur les développeurs oracle est déja non conforme, car si vous considerez la discipline comme un axe et la ville comme un axe, alors chacune de ses informations doit être référencée dans une table indépendante. C'est peut etre d'ailleurs là la source de nos divergences, car pour moi une colonne autre qu'indifiante n'est qu'une propriété d'élément, tant qu'il n'y a pas une table référençant de manières unique toutes ces propriétés possibles on ne peux pas la considerer comme un axe.

Sur l'exemple de nuke_y, c'est pareil, sa table TABLE ne contient que les relations, il faut lui rajouter une table par dimension si on veut une implémentation conforme voici ce que ça donnerait:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
T_SOC:
 
SOC_ID	SOC_INFO
------  ---------
A	Société tartemuche
B	SARL tartempion
C	EURL bidulle
 
 
T_SRV:
 
SRV_ID	SRV_INFO
-----	--------
1	Service commercial
2	Service technique
 
 
T_MAT:
 
MAT_ID	MAT_INFO
----	-----------
A_001	Robert
A_002	Lucette
A_003	jean
B_001	albert
B_002	benedicte

et enfin:

Code :

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

1
2
3
4
5
6
7
8
9
 
TABLE
 
SOCIETE SERVICE MATRICULE
A           1           A_001
A           1           A_002
A           2           A_003
B           2           B_001
C           1           C_001

si on veut projeter sur l'axe des sociétés l'axe des service en ne gardant que les services techniques alors on fait:

Code :

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

1
2
3
4
5
6
select *
from T_SOC
where EXISTS (
  SELECT * from TABLE 
  where TABLE.SOCIETE=T_SOC.SOC_ID
     and TABLE.SERVICE = 2 )

Si on veut la projection donnant l'ensemble des relations possibles SOCIETE/SERVICE alors on peut faire:

Code :

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

1
2
3
4
5
6
select *
from T_SOC,T_SRV
where EXISTS (
  SELECT * from TABLE 
  where TABLE.SOCIETE=T_SOC.SOC_ID
     and TABLE.SERVICE = T_SRV.SRV_ID )

c'est à dessein que je laisse "select *" partout pour souligner le fait que ce n'est pas le select qui donne l'information au sens pur mais le FROM. Le select lui ne s'occupe que d'affichage ce qui n'est pas pareil.
Dans la premiere requête, je ne projette que sur un axe alors je n'ai qu'une table derriere le from, dans la 2ieme je projette sur 2 axes donc j'ai 2 tables...

Ensuite je suis d'accord que le problème se pose lorsqu'on ressert le résultat du select dans une autre, à ce moment là, c'est au développeur de veiller à ce qu'il n'y ai pas de perte d'information en ramenant toujours l'ensemble des identifiant de ses axes. J'avoue ignorer ce qu'étaient les 1ieres versions de SQL et je pensais comme Fred que le EXISTS en avait toujours fait partie, en tout cas je trouve un peu rapide de le releguer au rang de "rustine"...


Remarque subsidiaire:
On peut regretter que la pratique du SQL se soit éloignée de la théorie des ensembles, ceci a pour moi une explication simple et bassement matérielle:

Les micro-processeurs ne fonctionnent pas de manière ensembliste mais de manière itérative, la mémoire a une strucure séquentielle.
Il ne faut pas oublier que l'informatique est une évolution de l'electronique, elle a été inventée au départ par des electroniciens qui en avaient mare de faire trop de soudures. Grace au couple memoire/processeur, ils ont créé un équipement générique qui n'était plus dédié à une tache particulière.
Pour faire fonctionner couple mémoire/calculateur, on lui a tout de suite collé un élément essentiel: l'horloge. Toute la logique de l'informatique a été scélée par ce simple ajout, un calcul élémentaire suit un autre calcul élémentaire le tout synchronisé par l'horloge. Depuis, des générations d'informaticiens raisonnent en "séquence", et donc la vision ensembliste par son aspect "hors du temps" a du mal à s'intégrer dans les machines (qui ne sont pas concues pour ça au départ) et surtout dans les cerveaux d'informaticiens qui ne sont pas du tout formatés dans cet esprit...
Voilà pourquoi lorsqu'on fait une jointure en SQL, un mathématicien pense "projection" alors que l'informaticien pense "boucle imbriquée" et comme c'est ce dernier qui programme, c'est ce dernier qui décide....

[orafrance]

table = ensemble de données organisé en lignes et colonnes et dont la valeur de chaque ligne est unique (contient au moins une valeur de colonne différente par rapport aux valeurs contenues dans les autres lignes pour la même colonne).

c'est justement là qu'on ne peut pas s'entendre si j'puis dire

En effet, je ne me rappelle pas qu'une telle contrainte soit obligatoire en SQL. Tout au plus, le voit on en modélisation Merise si tant est qu'on aille suffisamment loin dans la normalisation. Imagine que tu souhaites faire un table qui logue simplement toutes les heures à laquelle un message est posté sur ce forum. Tu pourrais très bien te suffire de la date compléte si c'est la seul info qui t'intéresse... dans ce cas, tu peux bien te retrouver avec des messages postées exactement simultanément et donc des lignes identiques. A quel titre devrions nous interdire ce modéle ? A quoi donc servirait les fonctions d'agrégation si toutes les lignes étaient distinctes ? Pourquoi créer la notion de PK si les lignes sont toutes uniques ? Dans le monde pratique qui nous intéresse, je ne vois pas quel pourrait être l'intérêt de ce que tu décris... note que je ne le rejette pas pour autant

[orafrance]

Certes. Simplement, je sui tombé sur une discussion portant sur EXISTS, sujet fort intéressant à lui tout seul.

mais quel rapport entre EXISTS et ce que tu décris comme étant le SQL qu'on devrait avoir ? C'est pas en garantissant l'unicité des données que tu sauras si une valeur EXISTE ou pas dans un ensemble... j'ai raté un wagon visiblement

[orafrance]

Voilà pourquoi lorsqu'on fait une jointure en SQL, un mathématicien pense "projection" alors que l'informaticien pense "boucle imbriquée" et comme c'est ce dernier qui programme, c'est ce dernier qui décide....

+1 il n'y a qu'à voir l'usage excessif du PL/SQL chez les développeurs pour s'en convaincre

[fsmrel]

Éliminer les doublons par projection ou autre opération relationnelle entraîne stabilité. En effet, au lieu de s’attendre à un nombre aléatoire de lignes en double au fil de l’exécution d’une requête donnée, on sait d’avance que le système ne produit qu’un exemplaire unique de ces lignes, ce qui revêt un caractère rassurant d’invariance, de stabilité dans le comportement. Pensez encore à l’opérateur UNION qui ne produit pas de doublons : qui s’en offusque ?

Mais alors que fais tu du UNION ALL ? Tu serais donc en train d'affirmer que l'UNION ALL est inutile ? Pour moi, un UNION ALL qui retourne deux lignes identiques c'est soit une erreur de conception (2 lignes identiques dans deux tables différentes) soit un besoin fonctionnel (table parent + table enfant, un enfant peut être un parent et je ne veux pas perdre l'information).

Bonne question. Je réponds que tout simplement l'opérateur UNION ALL n’est pas un opérateur relationnel. Il a été rajouté à SQL à la fin des années quatre-vingts, à la demande des développeurs, pour éviter une étape de tri, donc gagner un peu de temps, au détriment de la validité. UNION ALL ne concerne donc que le niveau réalisation (libre à l’éditeur de le proposer) mais pas le niveau modèle.

Je ne comprends pas bien l'intérêt de comparer l'arithmétique et les ensembles Dans ce cas, on peut surment s'intéresser aux dérivés et intégrales qui produisent des résultats surprenants. Ta comparaison est aussi hasardeuse que si j'affirmais qu'un carré ne peut être négatif et que je sortais l'exemple de l'irréel

En mathématiques, le concept de fermeture est fondamental. Je rappelle que Ted Codd a conçu le Modèle relationnel comme une branche des mathématiques appliquées.
Je ne hasarde rien, puisque je ne me fais que modestement l’écho des ténors du Relationnel (tous mathématiciens), qui ont écrit cela au début des années soixante-dix et le rappellent aujourd’hui encore.

le DISTINCT fait parti des opérateurs de la norme ANSI92 sans aucune ambiguité. Je t'invite à lire les articles sur http://sql.developpez.com dont Frédéric Brouard est à l'origine. Si tu es un spécialiste du SQL tu le connais surement

DISTINCT n’est pas un opérateur, c'est une condition, mais peu importe. Si DISTINCT fait partie de SQL, il ne fait pas partie du Modèle relationnel où il est sans objet, inutile, sans valeur ajoutée et n’a donc pas sa place. Maintenant, il est évident que lorsque je fais du SQL, je m’en sers pour qu’un résultat soit une table et pas un sac.

"Dans quelles villes trouve-t-on des spécialistes d’Oracle ?" :

alors inutile d’apprendre mille fois que Paris répond à la question, une fois suffit. Méditez ce qu’écrivait Guillaume d’Ockham il y a près de 700 ans : "Ne multipliez pas les entités au-delà du nécessaire".

Sauf si en plus j'ajoute l'information sur le nom de ces spécialistes. Si je ne veux pas voir Paris plusieurs fois, c'est la que l'aggrégation intervient... il est évident que si tout était unique les SUM n'existerait pas... sommer une ligne seule n'a aucun sens (ou alors je n'ai pas compris ta démonstration ce qui n'est pas impossible)

La question "Dans quelles villes trouve-t-on des spécialistes d’Oracle" n’est pas la même que la suivante : "Dans quelles villes trouve-t-on des spécialistes d’Oracle et combien sont-ils (en tout ou pour chacune d’elles)". Il est évident que pour répondre à cette nouvelle question, je fais intervenir l’opérateur d’agrégation SUM, lequel fait partie du Modèle, tout comme COUNT, AVG, MIN, MAX.
Appliquons le rasoir d’Ockham : contrairement à le 2e, dans la 1re question on ne demande pas combien y a-t-il de spécialistes d’Oracle, mais simplement s’il y en a, auquel cas je n’ai pas à compter.

L’algèbre relationnelle est complète (permet de produire tous les résultats possibles) sans ajouter des rustines telles que EXISTS (ou DISTINCT...) Je rappelle que (NOT) EXISTS a été ajouté à SQL pour pallier l’absence initiale de l’opérateur ensembliste MINUS (rebaptisé INTERSECT dans certains dialectes) indispensable pour qu’un langage relationnel soit complet.

Je suis navré mais tu parles de facilités techniques qui remplacent des opérations sur les ensembles. Le MINUS est d'ailleurs une catastrophe, heureusement que les SGBD ont mis en oeuvre le EXISTS. C'est un exemple parfait pour montrer que ce qui marche sur le papier ne marche pas forcément quand on le met en oeuvre. C'est toute la différence entre un algo et son programme. En revanche, je ne savais pas que MINUS était absent des SGBD et ça me laisse même perplexe puisqu'en ce qui concerne Oracle ça existe depuis la V6 (autant dire un autre temps)

Encore une fois, je parle du Modèle et pas de la réalisation qu’on en fait. MINUS est peut-être catastrophique en termes de temps de réponse avec certains SGBD. Si tel est le cas avec Oracle en particulier, alors il est du ressort de l’éditeur de ce SGBD d’améliorer l’optimiseur en transformant sous le capot une requête avec MINUS en requête du type NOT EXISTS, de façon transparente pour le développeur. Ça n’est pas à celui-ci de pallier la mauvaise performance de son SGBD, mais il peut réclamer qu’un opérateur soit rendu décemment exploitable.

En passant, il y a une coquille dans ce que j’ai écrit et que j’ai corrigé par ailleurs : il ne faut pas lire "rebaptisé INTERSECT" mais "rebaptisé EXCEPT" (EXCEPT est du reste le nom donné à MINUS dans le Standard).
Pour la petite histoire, MINUS (comme INTERSECT) n’a pas toujours été mis en œuvre par les SGBD. En existe-t-il qui ne proposent toujours pas cet opérateur ? Ça arrive. Par exemple, si DB2 pour Unix le propose (avec le nom EXCEPT), ça n’est pas le cas DB2 for z/OS V8 (ça le sera avec la V9).

C’est dans mon esprit, mais ce le fut surtout dans celui de Ted Codd, père du Modèle relationnel (modèle dont SQL se réclame, tout en oubliant d’en appliquer les règles) : éliminer les doublons pour rester dans la théorie des ensembles. Par ailleurs, Le Modèle relationnel n’est pas un outil informatique mais une branche des mathématiques appliquées : nuance ! Je répète ce que je viens de dire : comme SQL n’applique pas correctement la projection, la restriction et la jointure, c’est vous qui en pâtissez en devant jongler avec les rustines ad-hoc DISTINCT, EXISTS et compagnie.

Mais si les SGBD ne s'adaptaient pas aux besoins de la "vraie" vie on ne s'en sortirait pas. Je reviens sur le MINUS. Fais donc un MINUS entre deux tables de plusieurs millions de lignes, les indexes ne te seront d'aucun secours et les perfs seront catastrophiques. Alors oui, le SQL Oracle n'est pas le SQL ANSI qui n'est pas non plus des mathématiques au sens strict du terme (d'ailleurs le SQL se réclamerait plutôt de Merise que de Todd Codd).

Si l’opérateur MINUS d’Oracle n’est pas performant, dois-je en conclure que tous les SGBD sont mauvais à ce sujet ? Certes non. Selon l’EXPLAIN les index seraient disqualifiés ? Il est évident qu’en même temps que j’enverrai un courrier à l’éditeur (sans grande illusion), je quitterai la face Nord pour tenter la face Sud et utiliserai par exemple la condition EXISTS si cette fois-ci les index sont mis à profit. Mais le Modèle relationnel n’est pas responsable du mauvais comportement d’un opérateur en particulier, avec un SGBD donné. Je répète : le modèle est une chose, sa réalisation par Tartempion en est une autre.
Todd Codd : vous voulez sans doute parler de Ted Codd (qui fut récompensé par la Turing Award en 1981). Stephen Todd est aussi un grand nom dans l’histoire des SGBD (on lui doit le PRTV, Peterlee Relational Test Vehicle, datant de 1976, SGBD authentiquement relationnel).

Que vient faire Merise dans cette histoire ?! Merise est une méthode pour représenter la structure des données, certaines contraintes et les événements déclencheurs des traitements. Merise ne propose aucun opérateur. Tout ce que vous pouvez demander à un AGL en partant de Merise (ou plus généralement de l’entité/relation), c’est de générer des Create Table, des Create Index, plus généralement du DDL.

En revanche, SQL est bien un rejeton du Modèle relationnel. Il s’est d’abord appelé SEQUEL (mais a dû être renommé pour des raisons de copyright). Ce fut le langage utilisé par le prototype System R d’IBM, au milieu des années soixante-dix. Reportez-vous au document qui relate l’histoire de SQL, par ceux qui l’ont fait :

http://www.mcjones.org/System_R/SQL_...C-1997-018.pdf

Vous y apprendrez accessoirement (en termes mesurés sinon voilés) comment Larry Ellison a récupéré la grammaire de SQL, autant dire le dossier de conception...

je salue les évolutions apportées par les SGBD à une science qui ne répond pas au besoin de l'informatique

Chaque SGBD "relationnel" adhérant à SQL est une image déformée du Modèle relationnel et n’apporte strictement rien au plan scientifique. Par ailleurs, si ce modèle n’avait pas répondu à un besoin de l’informatique, IBM n’aurait jamais accepté de mettre en œuvre System R et les SGBDR commerciaux n’auraient pas vu le jour, à l’exception de Ingres, système relationnel utilisant le langage QUEL, authentiquement relationnel (que Larry Ellison aurait sans doute copié s’il n’avait eu que cela à se mettre sous la dent).

table = ensemble de données organisé en lignes et colonnes et dont la valeur de chaque ligne est unique (contient au moins une valeur de colonne différente par rapport aux valeurs contenues dans les autres lignes pour la même colonne).

c'est justement là qu'on ne peut pas s'entendre si j'puis dire

En effet, je ne me rappelle pas qu'une telle contrainte soit obligatoire en SQL. Tout au plus, le voit on en modélisation Merise si tant est qu'on aille suffisamment loin dans la normalisation. Imagine que tu souhaites faire un table qui logue simplement toutes les heures à laquelle un message est posté sur ce forum. Tu pourrais très bien te suffire de la date compléte si c'est la seul info qui t'intéresse... dans ce cas, tu peux bien te retrouver avec des messages postées exactement simultanément et donc des lignes identiques. A quel titre devrions nous interdire ce modéle ? A quoi donc servirait les fonctions d'agrégation si toutes les lignes étaient distinctes ? Pourquoi créer la notion de PK si les lignes sont toutes uniques ? Dans le monde pratique qui nous intéresse, je ne vois pas quel pourrait être l'intérêt de ce que tu décris... note que je ne le rejette pas pour autant

La contrainte d’unicité n’existe pas en SQL, donc comme je l’ai déjà dit, ce qu’on manipule n’est pas une table mais un sac (tuple bag).

Si l’algèbre des sacs vous intéresse, je vous suggère de lire les articles :

http://www.dbdebunk.com/page/page/627052.htm

http://www.dbdebunk.com/page/page/638922.htm

Merise exige que chaque entité soit identifiée : Je ne peux qu’adhérer à cette exigence.

Concernant les messages postés sur ce forum, je les identifie eux aussi puisque je ne connais que l’algèbre relationnelle et pas celle des sacs. Maintenant, si je veux utiliser les fonctions d’agrégation, je ne vois pas où est le problème. Avec l’algèbre relationnelle j’utilise l’opérateur SUMMARIZE, en SQL j’en passe par un GROUP BY appliqué aux colonnes pertinentes.

A quel titre interdire ce modèle ? Personnellement je n’interdis rien. Je suggère seulement d’utiliser une algèbre mathématiquement valide plutôt qu’une algèbre bien compliquée et dont la validité reste à prouver.

Pourquoi avoir créé la notion de PK ? Tout simplement parce qu’au niveau des tables (je reste au niveau modèle, je ne parle pas des index UNIQUE) c’est techniquement la seule façon, non seulement de garantir l’unicité des lignes, mais aussi le principe d’irréductibilité : une clé est réductible si certaines des colonnes qui la composent peuvent en être évacuées, sans que la propriété d’unicité en souffre. C’est l’application du rasoir d’Ockham. Si la colonne Dev_Id suffit pour rendre unique chaque ligne de la table des développeurs, non seulement il est inutile mais dangereux de rajouter d’autres colonnes de la table dans la clé (on perdrait une règle de gestion très forte).

La notion de PK, ou plutôt de clé candidate, permet aussi de mettre en oeuvre l’intégrité référentielle, ce qui n’est pas rien en ce qui concerne la validité de la base de données...

Dans le monde pratique qui m’intéresse, le Modèle relationnel que je décris (ou plutôt évoque ici) me fournit des opérateurs puissants, en petit nombre et une garantie supérieure en termes de validité. J’ai utilisé les principaux SGBD pré-relationnels (j'en ai même réécrit un, tout seul, pour le compte d'un banquier suisse qui le trouvait trop lent), quelques SGBD relationnels et aujourd’hui je suis à même de tirer des conclusions. Je répète que je suis intervenu très concrètement dans de nombreuses entreprises, baroudé dans des bases de données pas possibles et pense avoir regardé les choses par le bon bout de la lorgnette.

[orafrance]

Intéressant

Je ne répondrais que sur le point sur lequel je suis le plus compétent, le MINUS et les indexes. En effet, il aurait pu être intéressant qu'Oracle améliore l'optimiseur pour transformer le MINUS en NOT EXISTS... sauf que pour qui a fait de l'optimisation de code, on sait que NOT EXISTS peut avoir des revers et que dans ce cas le NOT IN est plus adapté (notamment quand l'ensemble exclu est très petit). Ainsi, de la même manière que je n'apprécie pas que le SGBD enléve les doublons alors que je veux unir 2 résultats, je n'apprécierais pas qu'il me limite à une seule solution (avec forcément un partie pris) pour faire une exclusion.

Du coup, je l'affirme haut et clair , j'aime Oracle justement parce qu'il propose des solutions techniques souples... dans un autre registre que le SQL, certain y préféreront SQL Server pour la simplicité de l'administration... mais finalement... n'est pas l'intérêt de la concurrence et de l'innovation

[fsmrel]

Je ne répondrais que sur le point sur lequel je suis le plus compétent, le MINUS et les indexes. En effet, il aurait pu être intéressant qu'Oracle améliore l'optimiseur pour transformer le MINUS en NOT EXISTS... sauf que pour qui a fait de l'optimisation de code, on sait que NOT EXISTS peut avoir des revers et que dans ce cas le NOT IN est plus adapté (notamment quand l'ensemble exclu est très petit).

A mon tour, je réponds en fonction du SGBD pour lequel je suis le plus compétent, à savoir DB2 for z/OS, fils légitime de System R. Même si ça n'est pas exactement comme cela que les choses se passent (ça n'est pas moi qui l'ai développé et concernant MINUS, il n'est pas encore à la disposition du développeur...), disons que les choses se passeront en gros comme cela quant à la stratégie :
Optimisation du MINUS sous le capot, en le remplaçant, par exemple, par un NOT EXISTS. Observation régulière par DB2 des événements : si la performance n'est pas satisfaisante, transformation au vol du NOT EXISTS par exemple en NOT IN. Observation ultérieure : ça n'est pas terrible ? Changement de stratégie toujours dynamiquement, etc.
Moralité, quand les choses se passent sous le capot, c'est bien, car on n'a pas à toucher pas aux requêtes. Evidemment, mon SGBD peut se tromper dans ses choix, mais ça n'est pas heureusement pas fréquent. Il n'y a pas de SGBD idéal, sinon ça se saurait.

[orafrance]

Tu veux dire que l'optimiseur DB2 sait changer de startégie "à la volée"... mais dans ce cas quel critère le décide à changer de stratégie ? C'est miraculeux comme optimiseur

[remi4444]

Je pense qu'on peut quand meme pas s'abstraire comme ça de ce qui se passe sous le capot. Et malheureusement pour les matematiciens ensemblistes, le coeur du moteur ne l'est pas... c'est alors le boulot de l'optimiseur de transformer les opération d'ensemble en algorhitme interprétable par un microprocesseur.
Mais ce n'est pas magique non plus, qu'on demande à l'optimiseur de transformer par permutations et tests successifs une requête simple portant sur 2 ou 3 tables, pas de soucis, mais dés que la complexité et le nombre de tables augmentent, l'optimiseur lui même va etre un ennorme consomateur de ressources parcequ'il aura ennormément de paramètres à prendre en compte.
Comme il ne peut mathématiquement pas tout tester dans un délais raisonnable, alors il choisi à prioris certains chemins, et selon que le SQL demande du IN, EXISTS, ou MINUS, il ne seras pas orienté vers le même alogorithme. Sauf cas particuliers comme le NOT IN/NOT EXISTS ou il peut choisir de faire tout seul une jointure externe, il sera influencé par la manière dont la requête est écrite. Comme Fred, moi aussi en tant que développeur j'aime bien avoir la main et une influence sur l'algorithme final de l'optimiseur, c'est pour ça que je privilégie presque toujours le EXISTS car sa syntaxe indique en elle meme le bon chemin à prendre. Mais j'aime bien aussi que les opérateur ensemblistes n'entrainent pas les meme traitement. Par exemple j'ai conçu un jour un espèce de requêteur générique pour un client dont le principe était la combinaison d'un grand nombre de requêtes simples. La solution la plus stable d'un point de vue performance était de combiner par des UNION et INTERSECT l'ensemble des resultats des requêtes simple (resultat ne ramenant que des identifiants). Heureusement que l'optimiseur ne s'amusait pas à transformer ça en combinaisons de not-in exists etc... car 1 fois sur 2 les temps auraient été catastrophiques.

fsmrel à raison, le SQL-Oracle tel qu'il est n'est pas du tout une syntaxe mathématique indépendante du système comme ses inventeurs l'auraient souhaités. Peut etre faudrait-il une sorte de "SQL conceptuel" indépendant de tout, que les dévellopeurs transformerait en SQL-pratique en fonction de ce qu'il savent sur la répartition des donnée, index présents etc...