Bonjour.

Utilisant actuellement Microsoft SQL (sites en PHP), le plus souvent en SQL procédural, je voulais savoir plusieurs choses :

1. Est-ce qu'il est compliqué de transformer un site du TSQL vers du MySQL ? Enfin, du coté de PHP, ça ne pose aucune difficulté, mais alors pour tout le code SQL, c'est dur ? Long ?

2. Est-ce qu'il existe des utilitaires (plus ou moins mauvais) qui permettent de transformer du TSQL en MySQL ? Ou bien, les cas échéant, des utilitaires qui vont souligner les points qui ne vont pas marcher sous MySQL ?

Merci d'avance pour toute suggestion.

Si ton site à été fait avec PDO tu change ça du côté PHP en 5 minutes, et je pense que les syntaxes sont simillaire entre MySQL et TSQL donc copié/coller

Si ton site à été fait avec PDO tu change ça du côté PHP en 5 minutes, et je pense que les syntaxes sont simillaire entre MySQL et TSQL donc copié/coller

Non ; sans PDO. Mais n'importe ; justement, du coté de PHP, y a pas de grosses difficultés. Enfin, lorsque je fais un code vraiment sale, ça peut prendre du temps. Mais sinon, ça va.

Quant à faire copier/coller, je sais pas si c'est vraiment une solution, car justement, il y a des différences (même si j'utilise TSQL à un niveau assez élémentaire). Différences quant aux types des variables (taille maxi. du VARCHAR par exemple : j'utilise parfois du VARCHAR(1000), voire du 4000, or sous MySQL, ça risque pas de marcher). Différences quant aux noms des fonctions ensuite : il y a généralement les équivalents (alors que l'inverse n'est pas vraie), encore faut-il les connaitre... Différences quant au syntaxe enfin : je ne vois pas là, comme ça, d'exemple qui va poser problème lors de transposition du TSQL à MySQL, mais j'en ai un bon dans le sens inverse : le "SELECT * FROM x LIMIT 10". J'imagine que du TSQL à MySQL, il y a aussi ce genre de problèmes qui se pose...)

c'est tout le problème d'utiliser une langue propriétaire, ou de coller à une syntaxe spécifique à un DBMS, après c'est bonbon pour passer à autre chose.

Le meilleure serait de tout réécrire avec du SQL standard bien propre, et d'utiliser PDO, si des changements sont à prévoir à l'avenir.

Le meilleure serait de tout réécrire avec du SQL standard bien propre, et d'utiliser PDO, si des changements sont à prévoir à l'avenir.

C'est pas faux.

C'est pas faux.

en fait, si, c'est faux.

ça, c'est juste:

Le meilleur serait de tout réécrire avec du SQL standard bien propre et d'utiliser PDO, si des changements sont à prévoir à l'avenir.

Ca n'existe pas le SQL standard.
D'un SGBD a un autre, les formats de date sont différents, les formats numériques sont différents, les longeurs de varchar sont différents, les fonctions sont différentes, le fulltext est différent, les tables méta sont différentes, ... L'autoincrément n'existe pas partout et bien sûr le LIMIT non plus. Et ne parlons même pas des fonctions procédurales TSQL, PL/SQL et autres équivalentes sous MySQL et Postgresql.

Alors, bien sûr on peut rester avec des requêtes qui font papa-maman, mais on perd toute la richesse des différents SGBD. Et si on utilise cette richesse, c'est difficile de passer d'une base à une autre. Mais on ne peut pas avoir le beurre et l'argent du beurre. Le but n'est pas non plus de disserter sur ce qu'il aurait fallu faire selon untel ou untel : il y a une situation qui est ce qu'elle est et un problème à résoudre.

Donc, pour revenir à ta question : le procédural dans SQL Server de Microsoft est sensiblement différent du procédural dans MySQL qui essaye davantage de ressembler à celui d'Oracle. En plus, dans MySQL, le procédural (fonctions, triggers, procédures stockées, ...) en est à son balbutiement, est mal documenté et très peu bavarde pour le debuggage.

Mais tu peux regarder ça
http://sourceforge.net/projects/tsql2mysql
et éventuellement poser des questions à l'auteur de ce blog qui a écrit ce programme
http://eriksdiary.blogspot.com/2006/09/ ... erter.html

ou encore ces outils http://t-sql-editor.qarchive.org/

D'accord.
Merci pour ton aide.

bien sûr on peut rester avec des requêtes qui font papa-maman

Tout à fait, du SQL standard (ou "commun"), qu'on utilisé sous PDO pour pouvoir le porter sur toutes les DB's qu'on veut..

Ceci dit, après une vague d'engouement dans ma jeunesse, je vais pour MySQL ou SQLITE. A moins d'avoir de gros doutes sur le sgbd qu'on va employer, c'est quasi tout le temps le meme, inutile alors de se compliquer la vie.

PDO unifie l'accès aux bases de données. Il n'unifie pas la syntaxe SQL.
Quand tu dois extraire le numéro de département à partir du code postal, tu auras toujours un LEFT pour certains SBGD, un SUBSTR avec le premier caractère numéroté 0 pour d'autres et un SUBSTR avec le premier caractère numéroté 1 pour les dernières.

Personnellement, j'avais commencé avec Pear:DB qui est un ancêtre de PDO et qui continue à bien fonctionner même s'il n'est plus maintenu.

Mais cela dit, c'est vrai : les cas où on change de base de données sont rarissimes. Donc à moins de savoir à l'avance (ou de se douter fortement) qu'il va y avoir un portage, je pense qu'il faut profiter pleinement les possibilités spécifiques de chaque SGBD.

PDO unifie l'accès aux bases de données. Il n'unifie pas la syntaxe SQL.
Quand tu dois extraire le numéro de département à partir du code postal, tu auras toujours un LEFT pour certains SBGD, un SUBSTR avec le premier caractère numéroté 0 pour d'autres et un SUBSTR avec le premier caractère numéroté 1 pour les dernières.

Oui, c'est vrai, il faut nuancer. Mais bon, a quoi bon se narguer de pouvoir porter son application sur pleins de dbms, s'il faut a chaque fois revoir toutes les requêtes.. ( on peut toujours s'avancer vers de l'orm, mais à nouveau, c'est limité.)

Enfin, si, je peux comprendre l'avantage net de pouvoir passer de db en db, mais je trouve que ça en enlève quasi entièrement l'intérêt (point de vue personnel et non complètement éclairé).

Personnellement, j'ai posé la question d'origine car j'utilise pour ma part Microsoft SQL Server sur mon ordi, et rien d'autre. Il s'avère que j'aurai à développer d'ici quelque temps un site qui va fonctionner sous MySQL.
C'est pour ça que je me demandais si vraiment, je dois installer le serveur MySQL sur mon ordinateur bien avant la sortie du site (ce qui m'embête très fortement) ou faire du code 100% compatible TSQL/MySQL (ce qui ne doit pas être si évident), ou bien si je peux compter sur un petit utilitaire qui va convertir (même très mal) toutes les procédures SQL quelques jours avant la sortie du site.

Voilà. C'était juste pour ça.