Discussion:Structured Query Language

Vocabulaire

c koi wikific et wikif (présent dans vos résumés ?)

---

en fait, wikific et wikif sont des abréviations d'un mot qui n'existe que dans l'univers wiki, le mot "wikification"! Quésako? Il s'agit de mettre des liens avec les [[ et ]] sur des mots (bien choisis : donc, qui renvoient déjà à un article ou bien susceptibles d'être un futur article) de l'article brut => un article avec des liens incorporés au texte, c'est plus intéressant!!
Et c'est aussi la mise en page, les mots mis en gras ou en italique, etc etc...

voili. Amitiés. Francis 20:39 nov 17, 2002 (CET)

---

Dans l'absolu cette page ne devrait-elle pas s'appeler 'Structured Query Language' ? Avec un redirect depuis 'SQL', évidemment
Ryo 18:19 mar 25, 2003 (CET) le standardisateur fou

Euh, si... Traroth 4 déc 2003 à 16:36 (CET)

Commande SQL particulière ?

"Wikipédia utilise SQL, et en particulier la commande..." Qu'est ce que cette commande a de particulier ? Ne faudrait-il pas mettre "comme par exemple la commande..." ?

Les avantages/inconvénient du SQL par rapport a un autre langage?

Je ne suis pas (pour l'instant) assez calé en la matière, mais l'article pourrait lister ce qu'apporte ce système plutot qu'un autre, non? Au fait, 1970 l'article de Codd, mais IBM développé le langage la meme année? (je ne vois que les anomalies)Nimportnawak 2 janvier 2006 à 22:41 (CET)

les versions wiki anglaises et italiennes sont plus complètes sur les limites du SQL

Lien externe mort

Bonjour,

Pendant plusieurs vérifications automatiques, et dans le cadre du projet correction des liens externes un lien était indisponible.

Merci de vérifier si il est bien indisponible et de le remplacer par une version archivée par Internet Archive si c'est le cas. Vous pouvez avoir plus d'informations sur la manière de faire ceci ici. Si le lien est disponible, merci de l'indiquer sur cette page, pour permettre l'amélioration du robot. Les erreurs rapportées sont :

• http://www.wiscorp.com/Whitemarsh
  • Dans Structured Query Language, le Fri Jan 27 21:36:16 2006, 404 Not Found
  • Dans Structured Query Language, le Tue Jan 31 23:10:24 2006, 404 Not Found

▪ Eskimbot ☼ 1 février 2006 à 01:47 (CET)

Pseudo-langage ??

Mais qu'est-ce donc qu'un 'pseudo-langage' ? Qu'est ce qui est 'pseudo' dans 'Structured Query Language' ? 24.73.169.250 15 avril 2007 à 01:53 (CEST)

blocage de l'article

Je bloque l'article car il y a une guerre d'éditions évidente entre deux utilisateurs. Afin de lever le blocage trois points doivent être résolus :

• la référence au langage ENGLISH n'est pas accepté, il faut donc ajouter une source.
• le terme SEQUEL semble désigner deux choses différentes, point à éclaircir
• les ouvrages de F. Brouard sont supprimés, merci d'expliquer en quoi ces ouvrages ne sont pas pertinents si tel est le cas.

Le blocage ne sera pas levé tant que ces points n'auront pas été éclaircis. --Pok148 (d) 16 février 2008 à 17:29 (CET)

Wikifeu

Bonjour, une demande d'intervention à été demandé pas l'ip 62.160.150.174. Je vous invite à faire vos commentaires sur la discussion (Wikipédia:Wikipompiers/Feu-20080605150427) pendant que j'évalue l'état des lieux :). Iluvalar (d) 5 juin 2008 à 18:31 (CEST)

Archive: J'ai déplacé une bonne partie de la PdD sur la page de feu. J'ai bien peur que les quelques arguments qui aurait pu être utiles pour l'article ont été noyés dans le conflit... Iluvalar (d) 5 août 2008 à 16:43 (CEST)

Réserves de Codd sur le SQL

Je vois qu'il y a une guerre d'édition sur le sujet. Je pense que l'ajout d'une demande de source, tout en laissant la phrase litigieuse, devrait permettre d'attendre calmement quelques temps. Si aucune source sérieuse à l'appui de l'affirmation n'a été ajouté dans l'article d'ici quelques semaines, il me semble que la suppression de la phrase litigieuse ira de soi ... Brunok (d) 6 septembre 2008 à 19:34 (CEST)

merci de ne pas modifier le Refnec ajouté par Brunok (d · c · b) et ajouté également hier, ce Refnec est totalement légitime au vue de Aide:Sourcer :

Obligatoirement : toute information contestée, par exemple par l'apposition de la balise ^{[réf. nécessaire]}.

Bon, j'ai fait quelques recherches sur le sujet.

Tout d'abord, je rappelle que la phrase litigieuse est :

« Malgré le succès du langage SQL qui a suivi, Codd dénoncera cet outil qu'il considère comme une interprétation incorrecte de ses théories. »

Je ne trouve pas de référence à une dénonciation vigoureuse du langage SQL par Codd.

Par contre, il est vrai que le SQL ne suis pas rigoureusement les règles de Codd.

Je trouve sur http://safari.oreilly.com/1565926978/orsqlter-FOREWORD :

« While many aspects of SQL conform to the original definitions of Codd's relational theory, many concessions were also made in its definition to facilitate performance, ease of use, or ease of implementation. For example, in Codd's language, a query result always consisted of distinct rows because, by definition, the "projection" operation eliminates duplicates. In SQL, duplicates can appear in the set of rows returned by a query unless the keyword DISTINCT appears in the query's SELECT list.

Furthermore, as a computer language, SQL has its quirks and shortcomings. An ideal language perhaps would be more orthogonal and regular, with fewer restrictions on which language elements can appear in which contexts. Some critics of SQL find fault with SQL's treatment of missing information (nulls), or with the fact that SQL often supports several ways to write the same query. »

Donc je pense qu'une réserve sur le fait que le SQL ne suit pas rigoureusement les règles de Codd est justifiée mais avec une formulation beaucoup moins polémique que la phrase actuelle. Brunok (d) 8 septembre 2008 à 22:34 (CEST)

A mon avis, le fait que SQL ne respecte pas les règles de Codd n'a aucun intérêt. Lisp ne respecte pas le lambda-calcul de Church, et Prolog n'est pas la même chose que les clauses de Horn, et personne jusque-là n'a pensé à en faire un fromage. Schtong (d) 12 novembre 2009 à 19:59 (CET)

L'opinion de Codd - ni de perrsonne d'autre - sur ce qu'est devenu SQL n'a d'ailleurs rien à faire dans la partie historique. Si il y a quelque chose d'intéressant à en raconter, faire une section "Critiques sur le langage SQL". Schtong (d)

Bibliographie

Modification de la bibliographie : retrait d'un livre sur MySQL et HP qui n'a rien à voir et ajout du livre "SQL en Concentré" de Kevin Kline (O'Reilley), une excellente référence.

Rectifications à apporter et commentaire sur commentaire

Premier point. Je lis ceci :

« La première version de SQL a été développée à IBM en premier en 1970 par Donald Chamberlain et Raymond Boyce »

1) Remplacer "Chamberlain" par "Chamberlin".

2) La première référence à SQL ne date pas de 1970, mais de décembre 1973 (quand SQL s'appelait SEQUEL).

Référence : R.F. Boyce and D. D. Chamberlin, "Using a Structured English Query language as a Data Definition Facility" IBM Technical Report RJ 1318, IBM Research Laboratory, San Jose, Calif., December 1973.

Deuxième point. Au sujet de la controverse "Réserves de Codd sur le SQL". Je cite Brunok :

« Je ne trouve pas de référence à une dénonciation vigoureuse du langage SQL par Codd. »

Évidemment, Codd ne rejette pas SQL en bloc. Mais, dans son ouvrage de 1990 "The Relational Model for Database Management - Version 2", chapitre 23 "Serious Flaws in SQL", Codd dénonce vigoureusement trois erreurs majeures concernant les versions de SQL et auxquelles il consacre ce chapitre. Je le cite :

« It appears that all present versions share the following three flaws:

1. they permit duplicate rows to exist in relations;

2. they fail to separate psychological features from logical features;

3. they fail to provide adequate support for the use of either three-valued or four-valued logic...

The devastating consequences of these properties are explained in this chapter... The flaws are serious enough to justify immediate action by vendors to remove them, and by users to avoid the consequences of the flaws as far as possible... »

(Fin de citation.)

Pour sa part, Chris Date, le compagnon de route de Ted Codd durant les années soixante-dix, quatre-vingts, est plus expéditif. Dans l’ouvrage qu’il a rédigé en compagnie de Hugh Darwen "Databases, Types, and the Relational Model, The Third Manifesto" (3e édition, 2007), vous lirez ceci au chapitre 7 "RM Proscriptions", je cite :

« RM Proscription 10: NOT SQL. »

A propos du type NULL

Salut,

Je sais qu'il y a quelques personnes qui ont une connaissance assez approfondie du SQL ici, et j'aimerai avoir quelques petites précisions, ça concerne le type NULL.

Vous savez tous que chaque valeur NULL doit être considérée comme "potentiellement" différente de toutes les autres valeurs NULL, ce qui fait que SELECT NULL = NULL donne le marqueur UNKNOWN.

Tous les SGBDR actuels considèrent comme différentes toutes entrées NULL lorsqu'il s'agit d'une clé UNIQUE, mais, je ne sais pas pourquoi, le mot clé DISTINCT ainsi que l'opérateur UNION les considèrent comme identiques. Je trouve ça un peu contradictoire, parce que cela signifie que l'algorithme de DISTINCT et UNION fonctionnent de cette façon : (NULL == NULL) = true.

Pour moi, cet écart rend la totalité des implantations de SQL irrespectuseunt de la 4ème règle de Codd :

The DBMS must allow each field to remain null (or empty). Specifically, it must support a representation of "missing information and inapplicable information" that is systematic, distinct from all regular values (for example, "distinct from zero or any other number", in the case of numeric values), and independent of data type. It is also implied that such representations must be manipulated by the DBMS in a systematic way.

Et dans une autre mesure, de la 3ème règle :

All information in the database is to be represented in one and only one way, namely by values in column positions within rows of tables.

Sur le doc de SQLite, on peut lire qu'ils souhaitaient au départ considérer les NULL différents dans tous les cas, mais que, étant donné que tous les SGBDR qu'ils ont testés ne fonctionnaient pas comme cela, ils ont suivi leurs traces. Je pense que c'est ce qui s'est également ce qu'il s'est passé pour la totalité des SGBD testés, les premières implantations ont commis cette erreur (Oracle ?), et les autres ont suivis. La norme de 2003 semble aussi avoir adopté cette "erreur" : http://en.wikipedia.org/wiki/Null_(SQL)#Grouping_and_sorting.

Est-ce que le fait de considérer les NULL distincts avec DISTINCT et UNION aurait-il pu amener des problèmes, et que c'est dans ce soucis de conception que cette exception a été créée ?

NB : On ne parle absolument pas du type NULL dans l'article :'-(.

Merci. --Rapha222 (d) 1 novembre 2009 à 18:24 (CET)

TCL PICK

le TCL (voir système d'exploitation Pick)

ce langage étant auto extensible et existant dans la langue de l'utilisateur (Francais, deutch, dutch, english,.....) presente de nombreux avantages sur SQL

* Principaux défauts reprochés à SQL (anglais)

Voilà le passage que Helios60 remet sur l'article avec dextérité, il a déjà eu des problèmes avec cet utilisateur il y a un an (voir discussions plus haut). Tant que le passage ne sera pas mieux rédigé, sourcé et complet, j'invite tous les rédacteur à le supprimer (comme ca a été le cas l'année passée). --Rapha222 (d) 3 novembre 2009 à 17:25 (CET)

Il a aussi remis ses affabulations sur les doutes de Codd sur SQL. Comme en 2008, en avril 2009 et en juillet 2009 : AUCUNE source fiable n'est données. Il n'y a nul besoin de donner un nouveau sursis avec un ref nec !

J'abonde dans le même sens. Il lui a été demandé et redemandé des sources secondaires pour ces passages. Si j'ai bien saisi, Helios est distributeur du SGBD Pick en France. Ça ne lui interdit pas de participer à Wikipédia, mais il doit se conformer strictement aux règles de la maison et cesser de tenter le passage en force. --Iluvalar (d) 3 novembre 2009 à 16:51 (CET)

Il distribue en fait *une* version plus ou moins open-source du machin

SQL ne respecte pas les regles de Codd voir plus haut pour la régle 4 je distribue une version opensource d'implantation de PICK mais je ne suis pas le seul a le faire puisque toute personne qui veux le faire en a le droit (licence GPL) --helios60 3 novembre 2009 à 20:51 (CET)

Et en quoi celà implique que Codd est contre le développement qu'a prit SQL ?

Par contre, je pense qu'il serait bien de mettre ce petit écart à la norme dans l'article si cela parait justifié et que l'on trouve des sources fiables.

SQL ne donne pas l'implantation recommandée pour l'unicité des NULL avant SQL:2003, donc le choix était laissé, ce qui rendait jusqu'à cette révision la norme respectueuse de la 4ème règle. Codd est mort avant la publication de SQL:2003. Comment Codd pouvait-il dire que la norme (la norme, pas ses implantations) ne respectait pas ses 13 directives alors que ce n'était pas encore le cas.

Et même si ces informations étaient vraies, il faudra bien que vous compreniez que tant qu'elles ne seront pas mises en formes et référencées, elles ne seront pas acceptées.

J'ai lancé la discussion sur le bistro.

--Rapha222 (d) 3 novembre 2009 à 21:36 (CET)

Mentionner TCL dans l'article est une bonne initiative, par contre le texte « ce langage étant auto extensible et existant dans la langue de l'utilisateur (Francais, deutch, dutch, english,.....) presente de nombreux avantages sur SQL » si il n'est pas sourcé relève du point de vue personnel du rédacteur (WP:POV). J'ai donc ajouté un lien sur Pick, sans autre indication.--Silex6 (d) 3 novembre 2009 à 22:18 (CET)

salut Helios60, quels sont tes sources. depuis février 2008 je pensais que tu avais compris la notion de source dans wikipedia ? Compte tenu de ton passif (confusion SEQUEL SQL notamment) il est difficile de prendre en compte des affirmations personnelles non sourcées. Pok148 (d) 6 novembre 2009 à 20:32 (CET)

source le TCL lui meme il suffit de prendre une doc du TCL d'un system PICK (Terminal Control Language) exemple celle de IBM ou CELLE de rainning data helios60 8 novembre 2009 à 10:21 (CET)

je te parlais de cette affirmation SQL ne respecte pas les regles de Codd voir plus haut pour la régle 4 Pok148 (d) 8 novembre 2009 à 15:19 (CET)

SQL n'est pas une implémentation du modèle relationnel. Une requête peut retourner deux fois la même ligne de résultat, on peut controler l'ordre des résultats, etc, toutes choses qui n'ont aucun strictement aucun sens dans un modèle ensembliste. Donc c'est un langage "inspiré" par le modèle relationnel. On peut faire des langages qui correspondent mieux au modèle relationnel, c'est certain. Sauf qu'apparemment ce n'est pas indispensable, ni spécialement pratique, et encore moins performant. Comme quoi ceux qui considèraient le modèle relationnel comme le modèle pratique de langage d'interrogation se fichaient le doigt dans l'oeil, Codd en premier.

Schtong (d) 13 novembre 2009 à 18:07 (CET)

Guerre d'édition

Suppression de plusieurs ouvrages de référence par un utilisateur anonyme dont le style rappelle étrangement un utilisateur bloqué récement.

Adresse IP correspondant de plus à un proxy :

[root@bignose root]# nmap 89.18.70.42

Starting nmap V. 2.54BETA22 ( www.insecure.org/nmap/ ) Interesting ports on 89-18-70-42.fwi.ie (89.18.70.42): (The 1535 ports scanned but not shown below are in state: closed) Port State Service 22/tcp open ssh 25/tcp filtered smtp 53/tcp open domain 135/tcp filtered loc-srv 445/tcp filtered microsoft-ds 2000/tcp open callbook 8080/tcp open http-proxy

Test du proxy => connexion à Google OK

Renommer l'article

Bonjour, comme il à été fait pour l'article PHP, il serait bien de renommer l'article Structured Query Language en SQL, je vous renvoi à la page de discussion de l'article PHP -> ici. Merci. Myst (d) 26 juillet 2010 à 02:19 (CEST)

1. Pour. la convention sur les titres prévois, pour les sigles, de nommer l'article avec le nom complet, à l'exception des cas ou le nom est inconnu et le sigle est courant. Le sigle SQL est courant et le nom complet est peu connu.--Silex6 (d) 26 juillet 2010 à 10:26 (CEST)
2. Pour : cela correspondrait aussi aux recherches des lecteurs et économiserait des ressources serveur. JackPotte ($♠) 27 juillet 2010 à 23:41 (CEST)
3. Pour : SQL est le nom courant. --Nimportnawak (d) 19 août 2010 à 14:56 (CEST)
4. Pour : SQL est le nom courant. comme PICK est le nom courrant pour un SGBD multivaleur ou Frigo pour un réfrigerateur --helios60 (d) 19 août 2010 à 18:57 (CEST)
5. Pour, on l'a fait pour LSD aussi. –Akeron (d) 23 août 2010 à 13:29 (CEST)

Le sens de "SQL"

Du premier paragraphe de l'article:"SQL (sigle de Structured Query Language) [...]". Selon le livre "Learning SQL" (2ième edition), cela n'est forcement pas vrai: [extrait, paragraphe 1.2 du livre]"Along with Codd's definition of the relational model, he proposed a language called DSL/Alpha for manipulating the data in relational tables. Shortly after Codd's paper was released, IBM commissioned a group to build a prototype based on Codd's ideas. This group created a simplified version of DSL/Alpha that they called SQUARE. Refinements to SQUARE led to a language called SEQUEL, which was, finally, renamed SQL. [...] One final note: SQL is not an acronym for anything (although many people will insist it stands for "Structured Query Language")."

(Excusez-moi mon français, je suis suédois d'origine.)

J'ajoute que dès l'introduction, Chris J. Date dans Introduction aux bases de données dit (p. 4 de la 8ème édition) que bien que SQL ait signifié structured query language à l'origine ce n'est plus une abréviation depuis que le langage est une norme internationale. Gokimines (discuter) 13 avril 2022 à 13:46 (CEST)

Pertinence des liens externes

J'ai ajouté le lien vers le site Developpez.com de SQLPro, alias Frédéric Brouard, dont les différentes édition du livre sont par ailleurs citées dans l'article. C'est une mine pour apprendre correctement le SQL. Je trouve par contre que le site SQLigo, de Donatien Celia, est en comparaison très pauvre. Il ne cite même pas les jointures qui sont pourtant indispensables dès que l'on veut interroger plus d'une table. Selon moi, ce lien n'a pas sa place sur Wikipedia mais je l'ai quand même laissé en attendant d'autres avis.--CinePhil (d) 13 mars 2012 à 19:27 (CET)