Hello,
j'ai un collegue qui a l'air d'apprecier particulierement la syntaxe:
 
insert into `a` set a=8,b=15
 
voici la structure de la table:
 
CREATE TABLE `a` (
  `a` int(11) NOT NULL,
  `b` int(11) NOT NULL
) ENGINE=MyISAM
 
 
mysql accepte sans probleme mais je me demande si je ne doit pas mettre le ola pour avoir une version plus standard.
le INSERT  via SET est il SQL Compliant ou est ce un résidue freestyle de mysql ?
 
J'ai essayé sous la version 5.0.27-community-log de cette dernier et ca passe toujours...
 
Merci de m'eclairer

Je n'ai jamais entendu parler de cette syntaxe.
 
Je suis prêt à affirmer que ce n'est pas SQL-92 compliant.
 
Après, ça peut éventuellement être nouveau avec les bases objet notamment, qui apportent des notions qu'un INSERT classique ne saura pas mieux gérer que ce truc bizarre.
 
En tout cas, pour une table classique, je pense que c'est très mal d'utiliser cette syntaxe. Outre le problème de normal, il y a un problème de lisibilité : un gars qui lis ça, il met 30 secondes à commence à imaginer comprendre ce que c'est censé faire. Et surtout, si c'est source d'une erreur, va se concentrer sur cette syntaxe étrange plutôt que sur la véritable raison du plantage. Bref, pas glop.

Salut,
 
je suis plutot de cet avis.
je precise par contre que ces requetes apparaissaient dans du vieux code c'est pour ca que j'ai essayé sur mysql 5 et ca passe a ma surprise alors qu'on m a dit que cette derniere etait plus rigoureuse que ces petites soeurs ...

A défaut de trouver la doc réelle du SQL 92, on fait avec les références qu'on trouve
 
http://en.wikipedia.org/wiki/Insert_(SQL)
 
Donc, le insert tout bête avec le mot clé "values", c'est la norme SQL "ancestrale".
 
Le SQL92 introduit les multiples tupes de valeurs (après "values", on trouve à la suite plusieurs tuples de valeurs entre parenthèses, séparés par des virgules).
 
Et on trouve aussi le INSERT à partir d'un sous-select.
 
Mais rien à propos de SET.
 
J'en déduit donc qu'il s'agit d'un truc purement proprio MySQL, comme le statement "REPLACE" qui permet de faire un INSERT ou UPDATE selon l'existance ou non de la clé primaire dans les valeurs passées en paramètres. Truc à éviter à tout prix si on veut garantir la pérénité du code et son portage sur d'autres SGBD.

merci pour tes recherches

Ceci dit, même si peut-être c'est bel et bien dans la norme (y'a le SQL 99 aussi entre autre, et je crois un 200x je sais pas combien), mon argument "le dev y voit ça, y soupçonne la syntaxe plutôt que l'algo" tiens toujours.
 
C'est un peu comme les optimisations capilotractées qu'on trouve parfois : la syntaxe est tellement "choquante" qu'il devient quasi impossible de faire de la maintenance sur le code, car le dev est trop dérouté par la syntaxe.
Genre en C, tu me parcours un array à grand coups d'offsets sur un pointeur plutôt qu'un itérateur, si à un moment je trouve n'importe quoi dans la tableau, je vais soupçonner direct la manière de lire en mémoire, plutôt que d'aller vérifier que j'ai pas écrit n'importe quoi un peu plus tôt.
 
Ici, ça peut même être pire, puisqu'après un coup d'oeil rapide (et une requête SQL, c'est rarement super bien lisible dans un code), à grands coups de "SET", le dev qui vient relire à 9 chances sur 10 de croire que tu fais un update, et donc ignorer la requête s'il recherche un insert.
 
C'est d'ailleurs une des recommandations du célèbre "How to design unmaintainable code" : jouer avec l'affectif du gars qui vient faire de la TMA, afin de lui rendre les choses les plus simples le plus difficile à comprendre.
http://mindprod.com/jgloss/unmainnaming.html => tips 17, 18