• # Concrètement...

    Posté par  . Évalué à 1.

    Pourquoi utiliser PostgreSQL au lieu d'une autre base (mysql par exemple) ?
    Quels sont ses avantage ?
    Question peut-être conne...

    • [^] # Re: Concrètement...

      Posté par  . Évalué à 4.

      Trop gros... passera pas !

    • [^] # Re: Concrètement...

      Posté par  . Évalué à 1.

      PostgreSQL est une base de donnee libre
      par rapport a mysql elle est faite pour les plus grosse base de donnee.
      Elle est utilise par exemple par les mormont aux etats-unis pour remplacee il me semble SQLServer.

      par contre PostgreSQL est moins simple a utiliser que MySQL ou les autres bases de donnee.

      Mais a la longue on s'y habitue.

      Cordialment

      • [^] # Re: Concrètement...

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

        par rapport a mysql elle est faite pour les plus grosse base de donnee.

        Pourquoi ?

        par contre PostgreSQL est moins simple a utiliser que MySQL ou les autres bases de donnee.

        Pourquoi ?

      • [^] # Re: Concrètement...

        Posté par  . Évalué à 2.

        Je n'aime pas mysql pour diverse raisons et je ne l'utilise presque pas, mais il faut remettre certaines choses à leur place:

        par rapport a mysql elle est faite pour les plus grosse base de donnee.


        Faux avec les dernières versions de mysql qui supporte des très grosses bases de données.

        par contre PostgreSQL est moins simple a utiliser que MySQL ou les autres bases de donnee.


        Il faudrait savoir ce que ça veux dire "utiliser":

        - si tu parle d'administration, j'ai du mal à savoir lequel est le plus simple, il y a peut-être plus de choses à faire pour avoir un PostgreSQL au petits oignons,

        - si tu parle d'utilisation, théoriquement il n'y aucune différence, tout bon devellopeur SQL doit se conformer à la norme SQL, donc si le langage est le même, je ne vois pas ce que cela change.

    • [^] # Re: Concrètement...

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

      PostgreSQL permet de poser des contraintes sur les types des éléments contenus dans la base, avec des valeurs par défaut, des champs qu'on peut forcer à être spécifiés, des choses comme ça.

      En fait, c'est peut-être aussi possible avec MySql, mais la personne qui m'a présenté PostgreSQL m'avait dit que c'était l'un de ses atouts importants.

      • [^] # Re: Concrètement...

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

        C'est aussi possible avec MySQL.

        • [^] # Re: Concrètement...

          Posté par  . Évalué à 4.

          procedure stockee, ... et des dizaines (centaines ?) d'autres fonctionnalites
          MySQL n'est actuellement pas un sgbdr car il ne respecte pas tout ce qu'un sgbdr est cense respecter ...

        • [^] # Re: Concrètement...

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

          Pas vraiment, en fait sous mysql il y a les énum pour restreindre a une liste de valeur pour un champ mais c'est loin des possibilités de PostgreSQL en la matiére (tu peux faire des contraintes calculés sur des valeurs d'autre champs.

          Pour les valeurs par defauts ça marche uniquement avec de constantes sous Mysql ,sous postgreSQL c'est bien plus évolué.

          Pour les Trigger sous MySQL c'est pas vraiment utilisable en l'état (pas de possibilité d'appeller une autre table par exemple, et puis il se déclenche pas à tous les coups (voir le truc des drop cascade)

          On peut aussi parler des clées composées en Innodb avec un auto increment.

          Enfin bref j'en ai des tas des comme ça, mais ça s'améliore.

          Ce qui m'ennerve un peu chez MySQL c'est ces commerciaux qui n'arrettent pas de mettre en avant toutes les supers fonctionalités de leur SGBD qui sont encore dans des versions de dev ou alors dans un état pas franchement utilisable.

    • [^] # Re: Concrètement...

      Posté par  . Évalué à 5.

      Je ne connais pas MySQL, mais d'après ce que j'ai pu lire ici et la, les intérets de PostgreSQL me semblent être dans ces différents points :
      - définition de nouveaux types, avec des operateurs associés
      - support de GiST pour les données qui ne sont pas ordonnable (comprendre : pas triable dans un arbre binaire de recherche, genre la geométrie)
      - une implémentation basé sur les paradigmes des SGBD objets (tout est objet, tout a un identifiant unique (oid), c'est a dire, y compris les tables, les types, les opérateurs, les tuples, les champs - enfin y'a peut être bien une coquille ou deux dans la liste).

      Bref, mon expérience limité des bases de données me donne l'impression que PosgreSQL est plus souple, plus "pure" dans sont implémentation. Je n'ai jamais eu de mauvaises surprises ni été déçu, ou seulement désapointé, que ce soit pour le SGBD lui même que pour les libs clientes (jbdc, libpq).

      A bien réfléchir, ce SGBD est tout simplement parfait à mes yeux, je ne trouve rien à redire :)

      • [^] # Re: Concrètement...

        Posté par  . Évalué à 1.

        (tout est objet, tout a un identifiant unique (oid)[...])


        C'est faux depuis les version 8, voir avant. Les OID sont maintenant optionnels et leurs utilisation est fortement déconseillée.

        Historiquement les OID sont sur 32bits, soit environ 4G possibilitées, ce qui n'est pas assez pour garantir une valeur unique de tout les objets d'une base pour peu qu'elle soit un peu imposante. Les objets sont toujours tous identifiables de manières unique mais par d'autres moyens, plus robustes et moins limités. Les tuples dans les tables doivent être identifiés par une clef primaire, à l'utilisateur de bien la définir.

        Pourquoi ne pas avoir étendu les OID sur 64 bits, je ne suis pas sûr mais je vois bien des raisons:
        - problème de performance sur les systèmes 32bits
        - cela n'aurait que repousser la limite
        - problème de compatibilité ascendante (les librairies et clients attendent des valeurs 32bits)
        - etc...

        • [^] # Re: Concrètement...

          Posté par  . Évalué à 2.

          Oups, merci de corriger ... je croyais les oid masqués par le systeme. Sinon, en analysant un peu les tables du systeme, les oid sont bien présents un peu parout pour identifier les tables, les types et autres composants du SGBD. Mais il semble que leur utilisation d'arrête là donc :)

    • [^] # Re: Concrètement...

      Posté par  . Évalué à 1.

      si je ne me trompe pas Mysql ne gere pas les requete imbrique contrairement a postgreSQL .

      apres le reste je sais pas

      • [^] # Re: Concrètement...

        Posté par  . Évalué à 3.

        Bah tu te trompes, il le gère depuis plusieurs versions. Depuis la 4.1 je crois.

    • [^] # Re: Concrètement...

      Posté par  . Évalué à 4.

      Parce que les commentaires sur MySQL dans Wikipédia sont à mourir de rire ?
      Dans tous les articles parlant des SGBD courants on a droit à la note suivante : "MySQL [5] Un serveur de bases de données relationnelles SQL très rapide, multithread, robuste et multi-utilisateurs." dans le § "Voir aussi".
      Comme si les autres SGBD ne l'étaient pas :p

    • [^] # Re: Concrètement...

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

      PostgreSQL gère très bien une chose qui n'a pas été mis en avant ici, ce sont les requêtes un tant soi peut complète, du genre select machin,truc from (select from where...) where (select from where)...

      Avec Postgre, tu peux faire de belles requêtes bien complexes, et il va te les exécuter à une vitesse phénoménale.

      MySQL, c'est bien pour faire select prenom, nom from client, mais dès que ça devient trop compliqué, il suit plus.

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: Concrètement...

      Posté par  . Évalué à 2.

      Pourquoi utiliser PostgreSQL à la place de MySQL ?

      Ben, je ne sais pas si TOUT le monde utilise la version 5.xx, qui fait tout mieux que la 4.yy, laquelle surpassait les 3.zz ......

      En tout cas, ça fait deux semaines que les dev chez moi s'emploient à "essayer" quelques trucs standards (croyaient ils): des requêtes imbriquées, des requêtes union qui donnent le résultat attendu, encore une fois les contraintes référentielles ...

      Dommage à notre époque de gérer encore soi-même des choses dont on ne s'occupe plus depuis des années par ailleurs.

      Faut dire que nos besoins en vitesse et en réplication sont bien en retrait par rapport aux possibilités de dev et aux contraintes d'exploitation.

      --
      Tout corps plongé dans un liquide en ressort mouillé.

  • # PostgreSQL pour les nuls ?

    Posté par  . Évalué à 2.

    Personnellement j'utilise mySQL.

    Pourtant PostgreSQL m'intéresse beaucoup.
    Mais je ne connais "rien" aux SGBD.

    J'ai déjà essayé de m'y plonger plusieurs fois, mais il y a tellement d'options, de possibilités, que je suis perdu, et que ça m'a découragé :'(

    Donc j'aimerais savoir si vous connaissez un bon site qui parle des fondaments des SGBD en les applicant à PostgreSQL ?

    Comme ça je fais d'une pierre deux coups, j'apprends à utiliser PostgreSQL et apprends correctement à utiliser une SGBD.

  • # Orthographe

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

    Je trouve la présentation de ton article très esthétique et agréable à parcourir. Il y a hélas de trop nombreuses fautes d'othographe et de grammaire qui gâchent un peu sa lecture. [1]

    Concernant le contenu je préfère ne pas me prononcer. Etant DBA depuis plus de 20 ans, mon jugement est beaucoup trop biaisé et même si j'adore et utilise PostgreSQL depuis plusieurs années, je ne trouve pas sa comparaison avec Oracle très pertinente (fonctions de clusterisation, partitionnement horizontal et vertical, etc.)

    Mais au moment où tous les grands acteurs (IBM, Oracle, Sybase) des SGBD sentent venir le danger et fournissent une version gratuite de leur outil (bridé soit par la taille des bases ou de la RAM, soit par le nombre de processeurs) il est bon de rappeler que PostGreSQL est une alternative tout à fait viable dans la très grande majorité des cas. En ce sens ton article revêt une importance toute particulière dans ce qui s'annonce être une véritable guerre de désinformation. (Quelle grande gueule ce Larry! )

    [1]
    * ligne 2: gestionnaire de bases de données (il peut y en avoir +ieurs ;)
    * ligne 6: PostgreSQL est un système de gestion de bases de données relationnelle -> c'est le système qui est relationnel
    * ligne 7: comparables à celles des ces -> de ses
    * les contraintes d’intégrités liées aux cléfs (on écrit clés ou clefs)
    * peut ensuite les utiliser dans toute l’applications
    * réalisons une fonction qui retourne tous les
    * Les choses commencent à être intéressantes
    * Cela peut-être très utile

    Je m'arrête là par manque de temps, mais il reste encore quelques petites coquilles.
    Bravo tout de même et bon w-e.

  • # Système de réplication poussif

    Posté par  . Évalué à 1.

    J'ai utilisé Postgresql pendant un temps et j'avais beaucoup apprécié les fonctionnalités et la rigueur du système.

    Depuis, je suis revenu sur MySQL pour des raisons indépendantes de ma volonté. MySQL me donne l'impression d'un soft un peu 'sale' et pas terminé. La version 5 est plus rigoureuse que la série des 4.1.x, mais il y a toujours cette impression d'inachevé. Je pense notamment au (non) support des transactions imbriquées.

    Combiné avec le côté 'pas propre' de la chose - ie. ouvrir une transaction dans une transaction provoque un commit de la transaction en cours et l'ouverture d'une nouvelle transaction sans aucun message d'erreur - c'est _impossible_ de faire des procédures stockées transactionnées. Ou alors on prend le risque de commiter la transaction en cours si l'utilisateur en avait ouvert une avant d'appeler la procédure. La conclusion, pour moi, c'est que les nouvelles fonctionnalités (procédures stockées, triggers, ...) de cette version 5 sont franchements limitées.

    Bref, il reste encore du boulot à faire sur MySQL, mais il faut reconnaître une chose : le système de réplication Master -> (n) Slave est très pratique et n'a pas d'équivalent sur Postgresql. C'est très dommage, d'autant plus que Postgresql intègre un log des écritures dans la base (comme MySQL) et qu'il suffirait de pas grand chose pour rejouer ce log en temps réel sur un ou plusieurs replicats, à la manière de MySQL.

    Alors OK, il y'a Slony qui permet de répliquer des bases Postgresql, je trouve le système un peu archaïque, peu sur et assez lourd (notamment si la structure de la base change de temps à autre).

  • # le plus mieux ....

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

    Un gros avantage, pour ceux qui ont besoin de développer dans le monde non libre: le prix!

    "PostgreSQL has a much simpler licensing scheme. It is released under the Berkley License, which allows for any use as long as a copy of the Berkley License is included with it. This means that you can release a commercial product that uses PostgreSQL or is a derivative of PostgreSQL without including source code."

    Une petite différence qui fait parfois toute la différence!

Suivre le flux des commentaires

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