Choix d'un moteur de base de données

[MarvinLeRouge]

Salut,

Je cherche à choisir un moteur de base de données approprié pour mon prochain projet (site web, pas vraiment de spécificités en termes de bdd).

Mon problème : après avoir lu quelques documents et vu quelques vidéos sur le non respect de MySQL pour l'intégrité des données, j'ai décidé qu'il ne fallait plus que je fasse confiance à MySQL.

Donc, je ne suis pas particulièrement pro-postgre ou pro-sqlite ou autre, je cherche essentiellement à voir :

• lesquels ne font pas les mêmes bêtises que MySQL
  
• lesquels gèrent bien les recherches full-text
  
• si ça peut valoir le coup de passer à du NoSQL et quelles conséquences ça aurait
  

Merci

N.B. : Je ne cherche pas à provoquer un flame sur "MySQL c'est pas bien" (ou le contraire); le respect de l'intégrité des données dont je parle concerne la modification de valeur sans prévenir "pour que ça rentre dans le type ou la taille de champ", le transtypage bizarroïde ou le résultat d'un simple "SELECT 1/0". Ces résultats sont aberrants et je veux donc passer à un autre outil pour mes bdd, c'est aussi simple que ça.

[SStephane]

Puisque le sujet n'est pas un troll, je vais simplement répondre que PG est très correct, les benchmarks le kiffent tout ça... mais n'en sachant pas plus sur ton projet (nécessité du transactionnel etc.), je ne vois pas ce que nos réponses pourraient apporter autre que "provoquer un flame sur "MySQL c'est pas bien" (ou le contraire);".

J'ai bien compris que t'aimais pas MySQL, aussi je serais curieux de savoir ce qui motive tes choix technologiques d'une manière générale. Il y aurait beaucoup à dire sur toutes les technos tels MySQL, PG, MSSQL, PHP, Java, .net etc. : tu pourras trouver des détracteurs pour tout, capables d'argumenter leurs choix et de convaincre tout le monde que c'est pas top : on n'est jamais totalement partial.

Je pense qu'il est aussi pas mal de revenir à la réalité de ton projet dans laquelle, sans vouloir t'offenser, MySQL suffit certainement.

En parlant de transtypage bizarroide, vas tu oublier PHP pour ton projet à cause du résultat de ce cast ?

<?php

echo (int) ( (0.1+0.7) * 10 );

Je t'invite à lire cette discussion présente dans mon marque page.

[jcaron]

Perso, je suis 100% Postresql depuis des années, mais je suis un type bizarre. J'utilise pgsql quand tout le monde utilise mysql, FreeBSD là où tout le monde est Linux, perl plutôt que php, Opera plutôt que Firefox ou Chrome, et j'en passe, donc je suis clairement en marge (mais je me soigne).

Postgresql a probablement une courbe d'apprentissage plus ardue que mysql en termes d'admin (mais ça c'est nettement amélioré ces dernières années). Il peut aussi y avoir quelques fonctionnalités qui sont absentes, parce qu'il y a un filtre assez fort à l'adoption de fonctions "pas tout à fait cuites". Mais une fois que c'est cuit, en général c'est nettement plus pointu que mysql.

N'oublie pas que de très, très nombreux outils ne connaissent que mysql. Choisir pgsql, ça implique dans de très nombreux cas de faire table rase de tout un tas de choses auxquelles tu peux être habitué...

Jacques.

[MarvinLeRouge]

Je suis intimement persuadé que, d'un point de vue capacité technique, MySQL répond aux besoins du projet (qui peut être considéré à une boutique en ligne du point de vue des fonctionnalités bdd).

Mais j'avoue que la constatation des erreurs MySQL comme le fait de modifier une donnée pour que ça colle au lieu de signaler que la donnée fournie ne colle pas au modèle m'a franchement refroidi sur son usage; à partir de là, choisir de l'utiliser signifie être certain avant tout appel à la bdd de la validité parfaite des données, ce qui pose la question de l'utilité réelle des contraintes de typage et de format des champs.

C'est pour ça que je cherche un autre sgbdr, qui se connecterait sans problème particulier aux différents frameworks php avec une couche d'abstraction, et qui aurait des outils type GUI permettant d'assurer la conception et la maintenance de la bdd.

P.S. @SStephane : j'avoue être tout aussi surpris par le résultat de ce cast; mais je sais aussi que je n'ai pas le temps d'apprendre un nouveau langage que php dans le temps nécessaire; alors qu'un changement de sgbdr ne nécessite pas forcément ça.

[Complément]

Il semblerait que MariaDB soit sujet à certains de ces bugs, mais pas à tous, notamment pas la coupure sauvage d'une donnée en cas de redimensionnement de colonne, ou l'insertion par défaut d'une chaine vide sur une colonne texte not null (un beau message d'erreur à la place).

[/Complément]

Modifié 13 Novembre 2013 par MarvinLeRouge