Si vous aviez mis la phrase dans l'autre sens ( code sql "Oracle" à faire tourner sur MySQL ) ou si vous aviez précisé la version de mysql ça aurait pu passer... mais :
En l'occurence les vieilles versions de MySQL n'ont qu'un nombre limité d'entorses connues (mais autorisées) à la norme SQL-3... j'ai relevé :
* le type INT auquel devrait être préféré le type INTEGER de la norme SQL-3,
* le type DEC auquel devrait être préféré le type DECIMAL,
* le type NUMERIC auquel devrait être préféré le type DECIMAL.
Et ces "entorses" étant comprises par Oracle (qui fait la même chose depuis plus longtemps) le code tournera sur Oracle sans modification.
Les versions récentes de MySQL convertissant à la volée INT en INTEGER et NUMERIC en DECIMAL à la création des champs (DEC n'étant même plus proposé), ce demi-problème n'est d'ailleurs plus d'actualité.
Dans l'autre sens en revanche Oracle "offre" un jeu d'entorses à la norme SQL-3 un peu plus grand (ce qui peut se comprendre : plus grosse bestiole et ausi nécessité de gérer la compatibilité ascendante)... et MySQL ne suit pas... ce qui n'est pas un mal.
Liste non exhaustive parce que je ne vais pas me peler la comparaison complète de la ref Oracle et de SQL-3 :
* BFILE qui corresponds à BLOB,
* INT auquel devrait être préféré le type INTEGER,
* DATE qui corresponds à DATETIME,
* LONG qui corresponds à BIGINT,
* LONG RAW qui corresponds à BIGINT,
* NCHAR qui corresponds à CHAR,
* NCLOB qui corresponds à TEXT,
* NUMBER qui corresponds à DECIMAL,
* NUMERIC auquel devrait être préféré le type DECIMAL,
* DEC auquel devrait être préféré le type DECIMAL,
* NVARCHAR2 qui corresponds à VARCHAR,
* RAW qui corresponds à BLOB,
* VARCHAR2 qui corresponds à VARCHAR.
Il y a aussi des types "Maison" qui n'ont pas d'équivalent dans la norme SQL-3 : NATURAL, POSITIVE, PLS_INTEGER, BINARY_INTEGER, SIMPLE_INTEGER, SIGNTYPE...
Sans compter quelques trucs plus tordus comme LOGGING, NOCACHE, NOPARALLEL, BYTE ... qui n'ont pas d'équivalent à ma connaissance dans la norme SQL-3. Ainsi que quelques détails sur CHAR et sur les implémentation des TRIGGERS (mais bon les TRIGGERS sur les vieilles versions de MySQL y'en a pas et sur les versions récentes c'est bien conforme à la norme SQL-3 si je ne m'abuse)
Bref... en réalité du code SQL qui passe pour MySQL a presque 100% de chances de tourner sur Oracle (la reciproque n'est pas "tout à fait vraie" encore huhuhu mais le SQL Oracle récent utilise assez peu ces types exotiques... sauf VARCHAR2 qu'on retrouve à toutes les sauces).
[^] # Re: ÉH! LES GENS !
Posté par maat . En réponse à la dépêche Et la guerre des formats bureautique continue. Évalué à 4.
Si vous aviez mis la phrase dans l'autre sens ( code sql "Oracle" à faire tourner sur MySQL ) ou si vous aviez précisé la version de mysql ça aurait pu passer... mais :
En l'occurence les vieilles versions de MySQL n'ont qu'un nombre limité d'entorses connues (mais autorisées) à la norme SQL-3... j'ai relevé :
* le type INT auquel devrait être préféré le type INTEGER de la norme SQL-3,
* le type DEC auquel devrait être préféré le type DECIMAL,
* le type NUMERIC auquel devrait être préféré le type DECIMAL.
Et ces "entorses" étant comprises par Oracle (qui fait la même chose depuis plus longtemps) le code tournera sur Oracle sans modification.
Les versions récentes de MySQL convertissant à la volée INT en INTEGER et NUMERIC en DECIMAL à la création des champs (DEC n'étant même plus proposé), ce demi-problème n'est d'ailleurs plus d'actualité.
Dans l'autre sens en revanche Oracle "offre" un jeu d'entorses à la norme SQL-3 un peu plus grand (ce qui peut se comprendre : plus grosse bestiole et ausi nécessité de gérer la compatibilité ascendante)... et MySQL ne suit pas... ce qui n'est pas un mal.
Liste non exhaustive parce que je ne vais pas me peler la comparaison complète de la ref Oracle et de SQL-3 :
* BFILE qui corresponds à BLOB,
* INT auquel devrait être préféré le type INTEGER,
* DATE qui corresponds à DATETIME,
* LONG qui corresponds à BIGINT,
* LONG RAW qui corresponds à BIGINT,
* NCHAR qui corresponds à CHAR,
* NCLOB qui corresponds à TEXT,
* NUMBER qui corresponds à DECIMAL,
* NUMERIC auquel devrait être préféré le type DECIMAL,
* DEC auquel devrait être préféré le type DECIMAL,
* NVARCHAR2 qui corresponds à VARCHAR,
* RAW qui corresponds à BLOB,
* VARCHAR2 qui corresponds à VARCHAR.
Il y a aussi des types "Maison" qui n'ont pas d'équivalent dans la norme SQL-3 : NATURAL, POSITIVE, PLS_INTEGER, BINARY_INTEGER, SIMPLE_INTEGER, SIGNTYPE...
Sans compter quelques trucs plus tordus comme LOGGING, NOCACHE, NOPARALLEL, BYTE ... qui n'ont pas d'équivalent à ma connaissance dans la norme SQL-3. Ainsi que quelques détails sur CHAR et sur les implémentation des TRIGGERS (mais bon les TRIGGERS sur les vieilles versions de MySQL y'en a pas et sur les versions récentes c'est bien conforme à la norme SQL-3 si je ne m'abuse)
Bref... en réalité du code SQL qui passe pour MySQL a presque 100% de chances de tourner sur Oracle (la reciproque n'est pas "tout à fait vraie" encore huhuhu mais le SQL Oracle récent utilise assez peu ces types exotiques... sauf VARCHAR2 qu'on retrouve à toutes les sauces).