Discussion :

[Chtulus]

Bonjour tout le monde,

C'est peut-être idiot mais je me pose la question depuis quelques temps et suite à quelques MP avec une personne (Peut-être vous dirais-je qui est-ce....?) :

mais il y a une question redondante dans ma tête, qui, je l'avoue n'a toujours pas trouvée de réponse.... Si une norme existe pourquoi la changer.... ? Personne n'as de réponses véritables, alors, ... c'est le même problème que virus et anti-virus....?

Et la réponse (qui m'a encouragé je l'avoue...)

Il y a plusieurs cas.
- Les fonctionnalités supplémentaires :
CONNECT BY d'Oracle ne semble pas être dans la norme, GROUP CONCAT non plus, ...
Parmi ces fonctionnalités hors normes, il y en a qui sont intéressantes, et certaines qui ont même des chances d'être intégrées aux normes suivantes
En fait, les innovations des éditeurs font avancer la norme.

- Par contre, j'ai plus de mal à comprendre les différences syntaxiques d'implémentations de certain trucs basics...
Pourquoi MySQL utilise CONCAT au lieu de || ?
Pourquoi Sybase, Oracle ont un opérateur de jointure externe particulier ?
Ils estiment peut être que la norme est mal foutue.
Qu'écrire :
WHERE a.clientid = b.clientid (+)
Est moins fatiguant que LEFT OUTER JOIN ON...
Je ne suis pas sûr par contre que les éditeurs outrepassent la norme juste pour se donner un style, ou pour éviter que le code écrit sur leur système soit incompréhensible par les autres...

Alors que peut-on dire là dessus ??? Certes trouver des suites

ont même des chances d'être intégrées aux normes suivantes

Comme dit plus haut c'est intéressant mais... N'est-ce pas tourner en rond ?

Je travaille sous SQL SERVER 2000, sous Access 2003 et 2007 et en PHP/MySQL. Et franchement j'avoue que... à force je suis perdus.

PS: Je sais je suis mauvais en Orthographe !!!

Si cela vous semble intéressant, alors, à vous !
(C'est dommage je n'ai pas trouvé comment la mettre en VRAI DISCUSSION !)

[Yanika_bzh]

Memes raisons que les normes ANSI ont été détournées par les éditeurs, pour protéger certains brevets de développement (composants internes) rendant ainsi les portabilités de moins en moins aisée.
De plus, certains moteurs ont une grammaire historique, des composants du moteurs sont plutôt anciens (mais pas forcement a réécrire) d'où des possibilités hors normes.

LE fait de travailler sous Oracle ou la grammaire SQL permet d'utiliser le (+) pour la jointure externe ne vous oblige pas a l'utiliser, le outer join fonctionne aussi très bien. Cela rend le code plus portable si un jour vous décidez de modifier votre SGBD.

Les chantiers de migration sont importants et si le developpeur par sa logique de développement la facilite dès le début, cela permet de gagner beaucoup de temps par la suite.

[Chtulus]

Salut Yanika_bzh,

permet d'utiliser le (+) pour la jointure externe ne vous oblige pas a l'utiliser, le outer join fonctionne aussi très bien.

Alors pourquoi changer..?

[Yanika_bzh]

Ce n'est pas changé, c'est harmonisé, normalisé...

ASE utilise (*), Oracle (+), ...
Il y a quelques années j'avais developpé un moteur de base de données, on avait choisit (#) ...
Alors qu'avec une norme tout le monde a la meme grammaire.

[Chtulus]

Merci de tes réponses,

Alors qu'avec une norme tout le monde a la meme grammaire.

Ben justement ce ne serait pas plus aisé... Alors pourquoi normaliser ?
Si chacun "harmonise" c'est comme dans la vie, si chacun fait ce qu'il veut sans limite, ça va être un beau bordel au bout d'un moment...

[CinePhil]

LEFT (OUTER est facultatif) JOIN est beaucoup plus compréhensible que WHERE a=b(+)
En plus ça permet de séparer les jointures de la restriction ce qui est également plus propre et plus facile à lire.

Quant à CONCAT chez MySQL au lieu de || :
|| est l'opérateur logique OU en php
CONCAT = Concaténer ce que tout le monde peut comprendre aisément

Les normes évoluent parce que la perfection n'est pas de ce monde.
Les améliorations sont parfois discutables mais l'évolution est un processus normal et sain.

[Yanika_bzh]

Les normes évoluent parce que la perfection n'est pas de ce monde.
Les améliorations sont parfois discutables mais l'évolution est un processus normal et sain.

Attention, ne pas confondre normalisation et amélioration, cela n'a rien a voir

[Chtulus]

En fait ce qu'il me semble surtout c'est que chacun essaie de ce distinguer pour avoir son propre language, basé sur une norme...

Certes on revient sur la notion d'évolution de la norme ! Qui alors ne sert à rien ! Quant on vois la diversité des SGBD et des langages, ça me mets le bourdon

[CinePhil]

Attention, ne pas confondre normalisation et amélioration, cela n'a rien a voir

Je parlais de l'amélioration engendrée par l'évolution de la norme.

Le processus normal devrait être :
1) Une norme minimale est établie
2) Les éditeurs font des logiciels qui a minima respectent la norme et y ajoutent éventuellement des fonctionnalités qu'ils jugent bénéfiques pour l'utilisateur
3) Le minima de la norme évolue en incluant des nouveautés :
- si elles figurent dans l'ensemble des logiciels qui respectent la norme
- ou si les éditeurs s'engagent à intégrer ces nouveautés dans leur prochaine version
- et dans les deux cas si ça fait partie de l'objet de la norme

Malheureusement, le 2) n'est déjà pas respecté par tous.

[Chtulus]

Là, je suis d'accord avec toi @Cinephil.

Prendre ce qui est déjà normalisé (Dans l'ensemble), et éventuellement, ajouter des fonctions en vue d'être intégré ultérieurement si leur utilisation favorise l'utilisateur final !

[ylarvor]

Chaque developpeur SQL devrait écrire au plus proche de la norme SQL 2003 pour améliorer l'interoperabilité de son code SQL. Le jour où l'on parle de migration inter-sgbd, cela devient crucial!

[fsmrel]

LEFT (OUTER est facultatif) JOIN est beaucoup plus compréhensible que WHERE a=b(+)

Il faut aller un peu plus loin. Je commence par citer SQLpro :

les jointures externes de SQL Server avec *= ne donnent pas les mêmes résultats que le OUTER JOIN !

Ensuite, voici ce qu'on lit dans Oracle® Database - SQL Language Reference 11g Release 1 (11.1)

To write a query that performs an outer join of tables A and B and returns all rows from A (a left outer join), use the LEFT [OUTER] JOIN syntax in the FROM clause, or apply the outer join operator (+) to all columns of B in the join condition in the WHERE clause.

To write a query that performs an outer join of tables A and B and returns all rows from B (a right outer join), use the RIGHT [OUTER] JOIN syntax in the FROM clause, or apply the outer join operator (+) to all columns of A in the join condition in the WHERE clause. For all rows in B that have no matching rows in A, Oracle returns null for any select list expressions containing columns of A.

To write a query that performs an outer join and returns all rows from A and B, extended with nulls if they do not satisfy the join condition (a full outer join), use the FULL [OUTER] JOIN syntax in the FROM clause.

Oracle recommends that you use the FROM clause OUTER JOIN syntax rather than the Oracle join operator. Outer join queries that use the Oracle join operator (+) are subject to the following rules and restrictions, which do not apply to the FROM clause OUTER JOIN syntax:

■ You cannot specify the (+) operator in a query block that also contains FROM clause join syntax.

■ The (+) operator can appear only in the WHERE clause or, in the context of left-correlation (when specifying the TABLE clause) in the FROM clause, and can be applied only to a column of a table or view.

■ ...

Mais pourquoi donc cette préconisation le l’OUTER JOIN conforme à la norme, au détriment de l’opérateur Join (+) ?
Au delà des restrictions diverses énumérées par Oracle, la réponse figure dans les ouvrages suivants de Chris Date :

[1]. Relational Database, Selected Writings First Edition (Reading, Mass.: Addison Wesley, 1986, "The Outer Join", initialement publié in Proc. 2nd International Conference on Databases, 1983).

[2]. Relational Database Writings 1989-1991 (Reading, Mass.: Addison-Wesley, 1992", Watch Out for Outer Join, initialement publié in InfoDB 5, N° 1 Spring/Summer 1990)

Date démontra que la jointure externe ne pouvait pas être exprimée par une "simple" extension au sein du trio SELECT-FROM-WHERE.

En conséquence, coder "WHERE A*= B" (ou "WHERE A=*B") comme avec SYBASE (ou SQL Server), cela permet de traiter quelques cas simples de LEFT OUTER JOIN et de RIGHT OUTER JOIN, et il est pratiquement impossible de définir exactement dans quels cas de figure les résultats peuvent être certifiés justes. En plus, ça ne fonctionne pas dans le cas général (FULL OUTER JOIN), cf. [2], page 317.

Cela vaut pour évidemment Oracle qui procéda au même genre d'extension ad-hoc : "WHERE A(+)=B" ou "WHERE A=B(+)".

Pour traiter correctement la jointure externe entre deux tables S et SP, Date démontra qu’il fallait :

Soit compléter le bloc SELECT-FROM-WHERE de la façon suivante : SELECT-FROM-WHERE-PRESERVE

Soit, de façon plus élégante, traiter l’opération en un seul bloc, au sein de la clause FROM :

S OUTER JOIN SP

Et il conclut par :

« I am glad to see that the SQL Standards committees are in fact planning such an extension in their proposal follow-on to the existing SQL standard known as SQL2. Here is the SQL2 formulation of the outer natural join...

SELECT *
FROM S NATURAL FULL OUTER JOIN SP ;

Not quite elegant as "S OUTER JOIN SP", perhaps, but a considerable improvement on most of what we have seen previously in this paper. »

=>

La norme a eu la bonne idée de s'inspirer des travaux de Date et les SGBD de suivre la norme.

[Chtulus]

Salut,

Je suis content des réponses obtenues mais un peu décu de si peu quand même...

[pacmann]

Salut !

Concernant la syntaxe de la jointure externe, j'ai lu quelque part qu'en fait c'est Oracle qui a introduit le concept.
Sauf que lorsqu'il a été introduit dans la norme, c'est une autre syntaxe qui a été choisie... (peut être à cause de ce que raconte Date )

Pour le coup du CONCAT, MySQL explique que c'est parce qu'ils utilisent déjà || comme opérateur logique (OR), comme en C.

J'ai pas mal rigolé en voyant la liste des "extensions à la norme ANSI SQL 92" que j'ai trouvée... mais j'ai encore plus rigolé quand j'ai lu qu'on peut lancer MySQL avec une option --ansi ! (j'aurai bien filé des liens, mais la dernière fois que j'ai posté un lien non developpez.com, je me suis fait taper dessus...)

Enfin bon, ce que je voulais ajouter, c'est qu'outre la portabilité des développements, il y a la portabilité des développeurs !
Avoir une norme, c'est un peu parler la même langue, et être capable d'interroger des SGBD sur les données indépendament des spécificités d'implémentation... c'est plutôt sympa, non ?

[SQLpro]

1) CONCAT et || existent tous deux dans la norme SQL

2) Je ne suis pas sûr par contre que les éditeurs outrepassent la norme juste pour se donner un style, ou pour éviter que le code écrit sur leur système soit incompréhensible par les autres...

Il y a deux choses : l'avance technologique et le fait de capturer sa clientèle.

L'avance techno c'est de proposé des fonctionnalités qui ne sont pas encore normalisées mais qui aident les techniciens. C'est souvent intéressant.

Le fait de capturer sa clientèle, c'est lorsque la norme à statué (par exemple sur les jointures externes ou la récursivité...), de continuer à imposer sa vision rétrograde afin de rendre les requêtes de tel éditeur difficile à porter dans un autre environnement. Oracle en a été l'exemple parfait en refusant les JOIN pendant 10 ans et en continuant à s'interdire les CTE et la récursivité à la norme (CONNECT BY...)... Du coup certains développement se font avec d'autres produits, plus simple, plus portables !
Car il ne faut jamais oublier que la norme est très intelligente puisque c'est la volonté collective des éditeurs, donc le bon sens, et cela conduit souvent à des expressions bien plus élégantes que celles fourbies par tel ou tel éditeur !

Je concluerait par une chose : apprenez la norme SQL plutôt que d'apprendre le SQL de tel ou tel éditeur, car vous ne vous y retrouverez pas. Ensuite une fois la norme maîtrisée, il sera simple pour vous de passer d'un dialecte à l'autre.

Ceux qui apprennent le dialecte MySQL ou PL/SQL doivent tout rapprendre dès qu'ils changent de SGBDR.

Apprendre le français littéraire, vous permettra aisément de parler l'argot ou le langage SMS. Je doute qu'en apprenant l'argot ou le SMS vous arriviez à comprendre le français !

Malheureusement je voit qu'une majorité de cours de prof d'université soit disant sur le langage SQL sont en fait sur le dialecte d'Oracle. Exemple Richard Grin à Sofia Antipolis, Yolaine Bourda à Supelec... Pour ne citer qu'eux.
Moi je me bat depuis des années pour faire apprendre le langage SQL (je l'enseigne aux Arts & Métiers PACA et à L'ISEN à Toulon) et tous mes ouvrages sur SQL sont sur la norme et non pas le SQL de truc ou de machin !

Vous apprendrez d'ailleurs bien des choses que vous n'avez jamais vu nulle part en lisant mes ouvrages et qui vont arriver dans les prochaines années dans les SGBDR....

A +

[Chtulus]

Bonjour,

Le débat reprend !!!

Merci pour vos réponses !

[Antoun]

Outre les diverses mauvaises raisons citées par SQLpro, il y a deux bonnes raisons

Au début, il n'y avait pas de norme ; chacun a donc développé ses bidouilles dans son coin. La norme est ensuite apparue (1986), comme compromis entre éditeurs. Chacun s'est donc retrouvé avec un certain nombre de syntaxes non normatives, mais par souci de compatibilité avec les versions antérieures, il a conservé ses syntaxes spécifiques à côté de la syntaxe normalisée.

De la même manière, un SGBD comme MySQL s'est développé postérieurement à la norme, mais en mode "bricolo" et donc sans toujours bien tenir compte de la norme. Quand l'affaire a pris un tour plus industriel, ils se sont rapproché de la norme mais en s'obligeant à garder la compatibilité avec les versions antérieures. C'est pourquoi || ne concatène pas, car c'est historiquement une variante du OR (au passage, il existe un @@SQL_MODE permettant de dire que le || est la concaténation et non un OR).

Seconde raison : les innovations des éditeurs. Le CONNECT BY d'Oracle, le GROUP_CONCAT de MySQL (pour ne prendre que celles que tu cites) sont des propositions intéressantes qui seront probablement à terme intégrées à la norme et copiées par les autres éditeurs. En attendant, cela fait partie du "pourquoi il faut choisir mon SGBD plutôt que celui de mes concurrents".

[SQLpro]

Non !...
Ni le CONNECT BY d'Oracle, ni le GROUP_CONCAT de MySQL n'ont été retenu (ce problème ayant déjà été tranché depuis longtemps par le comité !)
En effet CONNECT BY est bien moins puissant que la CTE récursive et contrevient à certains principes fondamentaux de SQL. Quand à GROUP_CONCAT il contrevient à un des principes fondamentaux de SQL : l'obligation d'ordre qui est par nature interdite pour une fonction d'agrégation.

Donc ces deux bidouilles sont mortes nés !

A +

[Chtulus]

Bonsoir,

Par contre j'ai lu quelque part ce serait Oracle Corporation qui aurait présenté la première version commercial de SQL. Certes imité, mais pourtant E.F. CODD aurait dénoncé ce SQL comme une interprétation incorrecte de ses théories.

Est-ce que je me mets tout de suite à lire des bouquins ou quelqu'un pourrait me dire quelles incohérences sont à constatées.

Sinon j'ai lu aussi qu'une nouvelle approche nommé Tutorial D serait plus cohérente que le SQL et plus simple (J'ai pas encore creusé la chose...). Il s'agit de faciliter l'enchâssement des commandes si j'ai bien compris le peu de lecture que j'ai eu. De plus ses auteurs (Hugues Darwen et Chris Date) trouvent que certains traitements de la valeur NULL sont mal traités dans certains cas, comme le fait de ne pas les intégrés dans la comparaison d'un champs différent à une valeur donnée.

Il y aurait aussi un language nommé Business System 12 je crois ?!!!

Quelques reproches : (Si vous voulez je pourrais vous donner le lien - site en anglais)

- Group By inconsistent and/or confusing
- Implementations are inconsistent between vendors
- Encourages long, hard-to-digest run-on "sentences"
- Updating one table based on values from another table is messy, especially if multiple columns need updating. (Perhaps that is bad normalization, but in practice sometimes it is necessary.)
- The formal specification is too damned huge

Voilà de but en blanc, je viens juste de finir ma petite lecture et je me pose encore plus de questions ?

[fsmrel]

Bonsoir,

j'ai lu quelque part

Où donc ?

ce serait Oracle Corporation qui aurait présenté la première version commercial de SQL.

En 1974, Chamberlin (IBM) présente SEQUEL :
"SEQUEL: A structured English query language". Proceedings of the 1974 ACM SIGFIDET (now SIGMOD) workshop on Data description, access and control. Ann Arbor, Michigan
Voyez http://www.almaden.ibm.com/cs/people...equel-1974.pdf

En 1976 : SEQUEL 2: A Unified Approach to Data Definition,
Voyez http://www.research.ibm.com/journal/...ibmrd2006E.pdf

En 1976, le prototype : "System R: Relational Approach to Database Management"

Pour des raisons de risque de copyright, SEQUEL devient SQL.

Voyez aussi "A History and Evaluation of System R" :
http://www.cs.berkeley.edu/~brewer/cs262/SystemR.pdf

Pour connaître l’histoire de System/R et du maraudage ellisonien le pompeur : "The 1995 SQL Reunion: People, Projects, and Politics"
Voyez http://www.mcjones.org/System_R/SQL_Reunion_95/

Après avoir consciencieusement cloné System/R, Larry Ellison a sorti Oracle en 1978-1979. IBM a sorti la version commerciale de System/R en 1981 sous le nom de SQL/DS. DB2 n’arrivera qu’en 1984.

Le professeur Miranda a appelé Oracle : "Le fils illégitime de System/R" ("Comprendre et concevoir les bases de données relationnelles" (éditests, 1988), voir page 108).

E.F. CODD aurait dénoncé ce SQL comme une interprétation incorrecte de ses théories.

Codd "n’aurait pas" mais "il a" !
Voyez son ouvrage : The Relational Model for Database Management: Version 2 (Reading, Mass.: Addison-Wesley, 1990). Le chapitre 23 "Serious Flaws in SQL" comporte 19 pages traitant des défauts.

Est-ce que je me mets tout de suite à lire des bouquins ou quelqu'un pourrait me dire quelles incohérences sont à constatées.

Je ne peux que vous conseiller de vous procurer l’ouvrage de Date :
C.J. Date. An Introduction to Database Systems, 8th edition. (Pearson: Addison-Wesley (International Edition), 2004).

Si ce n'est pas encore fait, voyez aussi par exemple "HAVING A Blunderful Time" de Darwen
http://www.dcs.warwick.ac.uk/~hugh/T...rful-Time.html

Sinon j'ai lu aussi qu'une nouvelle approche nommé Tutorial D serait plus cohérente que le SQL

Tutorial D a été très soigneusement conçu, en respectant les "Principles of good language design" chers à Date et Darwen (et à Codd (RIP) bien sûr). Tutorial D est un langage que l’on doit à Date et Darwen, Je cite :

«Tutorial D is a computationally complete programming language with full integrated database functionality. It is deliberately not meant to be "industrial strength"; rather, it is a "toy" language, whose principal purpose is to serve a teaching vehicle. As a consequence, many features that would be required in an industrial-strength language are intentionally omitted. (Extending the language to incorporate such features, thereby turning it into what might be called Industrial D, could be a worthwhile project) ...»

(C.J. Date, Hugh Darwen. Databases, Types, and the Relational Model The Third Manifesto, Third Edition (Pearson Addison-Wesley Longman, 2006)).
Notamment, pour les SGBD basés sur Tutorial D, voyez http://www.thethirdmanifesto.com/

(Hugues Darwen et Chris Date) trouvent que certains traitements de la valeur NULL sont mal traités

Ça fait partie des "flaws" de SQL : dans Tutorial D vous ne rencontrerez jamais le bonhomme Null.

Il y aurait aussi un language nommé Business System 12 je crois ?!!!

Assassiné par le Monstre en 1982.

Quelques reproches : (Si vous voulez je pourrais vous donner le lien - site en anglais)
Citation:
- Group By inconsistent and/or confusing
- Implementations are inconsistent between vendors
- Encourages long, hard-to-digest run-on "sentences"
- Updating one table based on values from another table is messy, especially if multiple columns need updating. (Perhaps that is bad normalization, but in practice sometimes it is necessary.)
- The formal specification is too damned huge

C’est plutôt vague et demande à être explicité et étayé.

Voilà de but en blanc, je viens juste de finir ma petite lecture et je me pose encore plus de questions ?

A nouveau : lisez C.J. Date. An Introduction to Database Systems, 8th edition. (Pearson: Addison-Wesley (International Edition), 2004).
Vous aurez les réponses, mais la lecture ne doit pas être superficielle.