Discussion :

[cjacquel]

Bonjour,

Quand choisi t'on mySQL à la place de MS SQL ?

Existe il un comparatif des avantages et inconvénients ?

Merci,
Christophe

[StringBuilder]

Euh... Comment dire en restant poli...

MySQL, c'est le choix par défaut du premier hurluberlu venu. Une démonstration puante d'absence totale de compétences.

SQL Server, c'est un choix qui se justifie, avec de véritables arguments (le premier, c'est un SGBD-R, lui).

Ensuite, d'autres choix s'offrent au développeur, comme Oracle, DB2, PostGreSQL pour ne citer que les plus connus, ainsi que SQL Lite, qui ne dispose que d'un seul avantage face à MySQL : celui d'être embarquable et disponible sur à peut près toutes les plateformes... Et c'est bien ses deux seuls mérites.

Bref, la question du payant/gratuit est une fausse question sur bien des points :
- MySQL n'est pas aussi gratuit qu'on croit, et sujet à des restrictions drastiques, la plus déconcertante étant que ton code client est de facto open source si tu utilises une base MySQL sans licence payée.
- SQL Server existe dans plusieurs versions gratuites, bien plus puissantes que MySQL (y compris en embarqué)
- Les économies sur le choix du SGBD se ressentent tout au long de la vie du logiciel par la suite, et peuvent rapidement coûter bien plus cher (arrêt des services, procédures de backup/reprise complexes voir impossibles, etc.)

Bon, après, vu que c'est vendredi dans moins de deux heures, je vais pas non plus donner trop à manger aux trolls, mais disons simplement que voilà... MySQL, soit on te l'impose et t'as le choix entre pleurer et faire avec, ou t'immoler par le feu. SQL Server, quand tu l'as, tu as la frite toute la journée.

Sinon, le très bon article de SQLpro est la référence pour étayer tout ce que je viens de dire :

http://blog.developpez.com/sqlpro/p9...oudre_aux_yeux

[skuatamad]

Je ne serais pas aussi catégorique... Évidemment je n'aime pas mysql moi non plus mais...

Mysql est le SGBD le plus utilisé dans le monde PHP, donc les CMS par exemple sont développés avec mysql, testés sur du mysql (et vite fait sur les autres), utilisés à 95% (voir plus) sur du mysql. Par ailleurs les nombreux modules qui les composent sont développés par une communauté qui bosse sur mysql.

Ok, bien sûr la plus part propose de s'interfacer avec d'autres SGBD mais avec ce choix on devient l'exception, voir un beta testeur...

Du coup dans un contexte CMS, je ne m'aventurerais a priori pas au delà de mysql.

- SQL Server existe dans plusieurs versions gratuites, bien plus puissantes que MySQL

Ok, le moteur SQL est plus puissant mais avec 1Go de RAM on ne fait pas tourner DVP par exemple, alors que mysql oui.
Tiens les forum de type phpbb... un autre exemple de solution conçue pour fonctionner avec mysql.

[StringBuilder]

Mysql est le SGBD le plus utilisé dans le monde PHP, donc les CMS par exemple sont développés avec mysql, testés sur du mysql (et vite fait sur les autres), utilisés à 95% (voir plus) sur du mysql. Par ailleurs les nombreux modules qui les composent sont développés par une communauté qui bosse sur mysql.

C'est pour ça que je dis que quand on prend MySQL, c'est pas par choix (et donc on n'a plus qu'à pleurer et faire avec, ou s'immoler )

Quant à la limitation de 1 Go pour la version Express, mouais, 1 point pour toi... Après, tu peux toujours éclater ta base sur plusieurs instances (une par catégorie du forum par exemple), et là t'as plus de souci
-> Quitte à faire de la bidouille, c'est pas pire que de devoir choisir entre le support des transactions ou celui du full text, ou bien devoir s’asseoir définitivement sur un backup synchrone à chaud (photo cohérente des données à un instant T, ce que je sais pas faire MySQL sans devoir arrêter la base) !

[DotNetMatt]

My 2 cents sur MySQL...

Youtube a commencé à exister en utilisant ce SGBDR pardon cette ignominie absolue. Résultat ils en étaient arrives à avoir une infrastructure de malade ! (i.e. des coûts de malade....) Ils ont ensuite décidé de contribuer au projet et de partager leurs développements. Mais aujourd'hui, et surtout depuis le rachat par Oracle, je pense que cela est terminé (je n'en mettrai pas ma main à couper).


Aussi, après avoir lu l'article de notre ami SQLPro, choisir MySQL est juste suicidaire. En alternative 100% gratuite, il faut préférer PostGreSQL. Ensuite Oracle XE reste un choix délicat car la courbe d'apprentissage sur le SGBD d'Oracle est très dissuasive, et il souffre de quelques retards débiles, comme par exemple la limite sur la longueur du nom des tables ou encore la limite à 1000 éléments dans une clause IN... Bref.

La meilleure alternative à PostGreSql reste SQL Server Express qui je pense surpasse tout le monde. Le NASDAQ a migré sur SQL Server, et quand on sait ce qu'ils doivent supporter comme charge et contraintes, ce n'est pas rien.

[Waldar]

Il n'y a rien d'alarmant tous les produits reçoivent régulièrement des mises à jour de sécurité, fort heureusement.

comme par exemple la limite sur la longueur du nom des tables ou encore la limite à 1000 éléments dans une clause IN... Bref.

Le premier point me fait parfois bondir (la limite est de trente caractères, c'est beaucoup trop court).
Je ne comprends pas pourquoi ils gardent cette limite historique.
Surtout que faire grandir des colonnes varchar, c'est ce qu'il y a de plus simple.
J'imagine bien que ça a un impact fort sur les tables systèmes, mais Oracle doit faire cette évolution.

Le second point est plus discutable, parce que le jour où il faut reprendre une requête avec un IN de mille éléments, en général on n'est pas content.
Le IN avec un select imbriqué est plus adapté aux "grandes listes".

[DotNetMatt]

Le second point est plus discutable, parce que le jour où il faut reprendre une requête avec un IN de mille éléments, en général on n'est pas content.
Le IN avec un select imbriqué est plus adapté aux "grandes listes".

C'est sûr mais j'ai en mémoire une expérience de migration avec Oracle rendue bien plus compliquée à cause de cette limitation. Contexte financier, il fallait migrer de grandes quantités de données. Dans certaines tables on ne voulait migrer que certains IDs, donc on avait opté pour un listing explicite, et parfois on arrivait à plus de 1000 éléments. On recevait les ID par un fichier Excel, puis on formattait la liste d'ID avec une formule qu'il suffisait ensuite de copier/coller dans la clause IN... Résultat on a dû se résoudre à rajouter des tables à notre modèle de migration (perte de temps puisque migration one shot et il fallait une avalanche d'autorisations pour pouvoir créer une simple table...). Certes pour les autorisations ce n'est pas la faute d'Oracle, mais il en résulte une perte de temps qu'on aurait pu éviter.

Autre exemple, avec un générateur de rapport. La requête SQL était automatiquement construite et lorsque le client voulait remonter des infos sur l'ensemble de ses comptes titres, alors il pouvait y avoir plus de 1000 éléments dans la clause IN... Au début on contournait en faisant des JOIN sur plusieurs SELECT dans le IN, mais cela n'était pas top pour les perfs et c'était assez peu lisible, donc au final on s'est mis à créer des tables temporaires pour stocker les IDs lorsque le client demandait la generation de son rapport, ce qui permettait d'utiliser un SELECT imbriqué dans le IN. Mais bon, au final il n'y a aucune plus-value à faire ca et ca oblige à rajouter du code juste pour contourner la limitation des 1000.