Forum Programmation.SQL Comparaison SGBDR

Posté par (page perso) .
Tags : aucun
2
29
sept.
2009
Bonjour,

Je me pose des questions concernant l'usage de MySQL comme SGBDR supportant une application de gestion du recrutement, de plus en plus ses limitations se font sentir.

La base est relativement légère, les tables principales tournent autour de 30K enregistrements mais nous avons une table qui frise avec le demi million de lignes.

Nous avons beaucoup de SELECT mais pas mal d'INSERT et d'UDPATEs également. Dans ce cadre MySQL m'a toujours semblé le plus adapté.

Les limitations auxquelles je suis confronté sont les suivantes :
- Absence de contraintes CHECK
- Impossibilité pour InnoDB de gérer les index fulltext

Je commence à me demander si je ne vais pas switcher pour
- pgSQL
- MS SQL
- Oracle

mais pour moi leurs inconvénients sont respectivement
- performance
- Obligation d'installer un serveur windows
- Prix

Est-ce que quelqu'un pourrait m'aiguiller vers un comparatif pas trop biaisé ou me donner des conseils ?

Merci !
  • # performance ?

    Posté par . Évalué à 5.

    Je ne trouvais pas que postgresql avait de gros problèmes de perfs.
    De toute façon, pour postgresql, rien ne t'empêche de monter une plateforme de test pour le tester.
    Et pour oracle, idem (avec les versions gratuites).
  • # Euh, postgreSQL

    Posté par . Évalué à 3.

    Me semble un bon choix. Si tu as des index bien propres sur tes tables, il sera au moins aussi performant que mysql.
    Tu peux mettre tout un tas de contraintes, et pas seulement des check, mais aussi des clefs étrangères par exemple.
    Le mieux, ce serait que tu fasses quelques tests sur une machine à part, pour voir si ça te convient vraiment avant de switcher définitivement de toutes façons.
    Juste pour te donner un retour positif, j'utilise postgresql depuis de nombreuses années maintenant, et je n'ai jamais eu le moindre problème avec. Et pourtant, je lui en demande, puisque j'ai quelques dizaines de bases de données, et ces bases sont faites de façon à être autonomes (comprendre par là qu'elles regorgent de triggers, contraintes, index, etc), de façon à ce que mes données soient toujours cohérentes, quel que soit l'outil utilisé pour attaquer la base (php, psql, phppgadmin, etc). Et je n'ai jamais eu à m'en plaindre.
  • # Merci

    Posté par (page perso) . Évalué à 1.

    ... pour vos retours !

    Est-ce que pgSQL gère les index fulltext comme mysql le fait avec le moteur MyISAM ?
  • # quelle version ?

    Posté par . Évalué à 2.

    MySQL a beaucoup progressé en performance dans les dernières versions, dixit même certains articles sur ce site.
    Quelle version de MySQL fait tu tourner ?
    As-tu passé les requêtes que tu trouves lente a un "explain plan" ?
    • [^] # Re: quelle version ?

      Posté par (page perso) . Évalué à 1.

      Je n'ai aucun problème de performance avec MySQL.
      Les configs InnoDB et MyISAM sont tunées à mort, et effectivement quand j'ai vraiment un souci particulier sur une requête, le EXPLAIN est très utile pour repérer les index manquants.

      En fait mon problème avec MySQL est qu'il manque de fonctionnalités, par exemple, j'aimerais bien ajouter des contraintes CHECK pour m'assurer que tous les enregistrements d'une table ont une date de début supérieure à la date de fin. Ou alors une contrainte CHECK pour vérifier que ((champ1 IS NULL AND champ2 IS NULL) OR (champ1 IS NOT NULL AND champ2 IS NOT NULL))

      Le support des procédures stockées n'est pas encore très mature, par exemple tu ne peux pas appeler de procédures à l'intérieur d'un curseur défini dans une première procédure,

      Les index fulltext ne sont pas supportés par InnoDB (du coup pas de transactions, row level locking etc) pour les tables qui comportent ces index

      Mais clairement, d'un point de vue performances je n'ai absolument rien à redire.

      Ce qu'il me faudrait idéalement c'est les perf de MySQL et les fonctionnalités de pgSQL avec un support Linux pour un prix raisonnable

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.