Journal mysql ou postgresql ?

Posté par  .
Étiquettes :
0
18
nov.
2003
Bonjour,

Suite à la news sur la sortie de postgresql, j'ai eu envie de connaitre votre avis sur mysql et postgresql : les différences, les avantages, les lacunes, la rapidité, les performances, etc.

Gurus de la base de donnée, manifeste toi !!! :)
  • # Re: mysql ou postgresql ?

    Posté par  (site web personnel) . Évalué à 3.

    Franchement, si tu connais bien les SGBDR (R=relationnel) et que tu recherche des fonctionnalités, n'hesite pas, prend postgresql, c'est incomparable a Mysql en terme de fonctionnalité (triggers, sequences, héritage, droits bcp plus fins, vues, contraintes ...).
    Mysql te permet quand meme de faire des devs plus rapides sur des petits projets vu que tu as moins de contraintes... Par contre, sur des projets plus gros, c'est interessant...

    Par contre, postgresql a la réputation d'etre bcp moins rapide que mysql (ceci dit, faut vraiment avoir besoin de perfs)... et il est vrai que postgresql est plus chiant a administrer que mysql ...

    PS : je suis un grand utilisateur des deux SGBD a titre perso et pro :)
    • [^] # Re: mysql ou postgresql ?

      Posté par  . Évalué à 0.

      En fait, c'est pas que Postgresql est tellement plus lent que Mysql, c'est qu'il n'a pas la même montée en charge.

      Mysql est rapide pour des traitements simples, mais sa montée en charge est de type exponentielle.
      Postgreql est (un peu?) plus lent pour des traitements simples, mais sa montée en charge est linéaire. Du coup, pas de surprise quand t'as beaucoup de données à traiter, etc.

      Donc faut voir. Mon seul reproche contre postgresql actuellement concernent la gestion des dates, cf plus bas.

      Mais niveau rapidité en général, je ne l'ai pas trouvé spécialement lent.
    • [^] # Re: mysql ou postgresql ?

      Posté par  . Évalué à 2.

      Pour moi y'a pas à hésiter non plus, c'est PostgreSQL. Je ne peux même pas imaginer me passer de vues.
  • # Re: mysql ou postgresql ?

    Posté par  . Évalué à 2.

    Ca dépend de l'utilisation.
    Personnellement, je me suis mis à Postgresql il y a 2 mois, et ca le fait.

    Seul point sur lequel je m'interroge: la gestion des dates.

    Je n'ai pas trouvé de champ timestamp numérique comme sous Mysql. Du coup, les dates&heures sont écrites en toutes lettres dans les tables, donc niveau maniement des données, c'est pas top top.

    De plus, le temps de traitement des requêtes avec des clauses where sur les champ de date (genre récupéré les enregistrement d'aujourd'hui) me semblent affreusement lentes. Pourtant, je n'ai pas énormement d'enregistrement (pour l'instant), peut être 10.000, pas tellement plus.
    • [^] # Re: mysql ou postgresql ?

      Posté par  (site web personnel) . Évalué à 1.

      where sur les champ de date (genre récupéré les enregistrement d'aujourd'hui) me semblent affreusement lentes

      meme en collant un index sur le champ ?

      Pour le timestamp numérique, tu peux toujours utiliser un entier... sauf à vouloir utiliser d'éventuelles fonctions de traitement de dates de PostgreSQL
      • [^] # Re: mysql ou postgresql ?

        Posté par  . Évalué à 1.

        > meme en collant un index sur le champ ?
        oui même avec un index..

        en fait, j'avais une requête avec un distinct et 2/3 left join, je n'ai jamais réussi à obtenir de résultat (mouline pdt 5 min, apres j'ai laissé tombé) sur ma base de prod avec une un certain nombre de millier d'enregistrement, par contre en local (avec une 100aine d'enreg), ca passait nickel.

        du coup, pour faire la même chose j'ai utilisé une requête imbriquée (WHERE mon_champ IN (SELECT ..) ), et la je suis passé à environ 5 sec de temps de traitement.

        C'est assez ennuyeux puisque dans ce cas précis, il s'agit de requêtes réalisées à partir de php pour faire des stats sur une page web, à partir des données insérées par une applis en java.
        Car 5 secondes, c'est quand même long. Du coup, je mets en cache mes pages html. Heureusement que je n'ai pas besoin de stats en temps réél...

        >Pour le timestamp numérique, tu peux toujours utiliser un entier... sauf à vouloir utiliser d'éventuelles fonctions de traitement de dates de PostgreSQL

        Oui, j'y ai pensé, mais ca veut dire changer pas mal de chose (ca n'est que récemment que je me suis apercu de ce problème.)

        J'ai pensé à autre chose: utiliser des entiers, et mettre un champ pour le jour, le mois, l'année, et les secondes..
        mais 4 champs au lieu d'un, c'est pas tiptop, et il reste le problème d'adapter le code..
        • [^] # Format date

          Posté par  . Évalué à 1.

          utiliser des entiers, et mettre un champ pour le jour, le mois, l'année, et les secondes..
          Ou utiliser une date julienne et une procéduer stockée qui remet tout ça sous forme lisible...
      • [^] # Re: mysql ou postgresql ?

        Posté par  (site web personnel) . Évalué à 2.

        Je suis allé sur la doc dynamique de postgresql 7.4.
        J'ai fait une recherche sur "date" et voilà les deux premiers résultats :
        - http://www.postgresql.org/docs/7.4/static/functions-datetime.html(...)
        - http://www.postgresql.org/docs/7.4/static/datatype-datetime.html(...)

        La deuxième page est intéressante, visiblement tu as des timestamp numériques (enfin si on parle de la même chose), en tout cas, ce n'est pas codé en texte dans la base de données.
        Prends le premier type de données "both date and time", il est codé sur 8 bits alors qu'il y a plus que 8 bits en texte (vu que ca va de -4713 à 5874897 avec précision en micro secondes)
        • [^] # Re: mysql ou postgresql ?

          Posté par  . Évalué à 1.

          timestamp [ (p) ] [ without time zone ] both date and time 8 bytes 4713 BC AD 1465001 1 microsecond / 14 digits

          hum...
          8 bytes. ca veut pas dire 8 octets en français, soit 64 bits ?

          En fait, je m'en fous un peu la manière dont c'est codé. Mais ce que je voudrais c'est qu'il y ait une méthode qui soit vraiment rapide.

          Avec mysql, il est recommandé d'utiliser un timestamp numérique, type unix (nombre de secondes depuis 1970), et tu utilises des fonctions de mysql pour éventuellement manipuler les données sous forme littéraire.

          Avec postgresql, y a bien des fonctions pour manipuler les dates, mais ca ne me semble pas tiptop, c'est tout.
          Je prendrais le temps de regarder ca de plus prêt, et de voir de quelle manière on obtient les meilleurs résultats.
    • [^] # Re: mysql ou postgresql ?

      Posté par  . Évalué à 1.

      Seul point sur lequel je m'interroge: la gestion des dates.

      Tu trouveras sans doute la réponse à tes questions ici : http://techdocs.postgresql.org/techdocs/faqdatesintervals.php(...)
  • # Re: mysql ou postgresql ?

    Posté par  . Évalué à 3.

    Y a cet article qui est pas mal qui explique les différences.

    http://www.phpteam.net/affiche.php?quoi=postgres-mysql1(...)

    Pour résumer mysql est plus rapide et postgre supporte une plus grande charge.
    Pour ce qui est des fonctionalités il y aura convergence dans le futur.
  • # Re: mysql ou postgresql ?

    Posté par  . Évalué à 1.

    Et qu'est ce qu'il en est de FirebirdSQL ?

Suivre le flux des commentaires

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