Sortie de PostgreSQL 8.3

Posté par  . Modéré par Mouns.
Étiquettes :
1
6
fév.
2008
Base de données
Le 4 février 2008, le groupe de développement PostgreSQL (PostgreSQL Global Development Group) a publié la tant attendue version 8.3 de la base de données libre la plus avancée au monde.

Concernant les performances, cette nouvelle version perpétue la montée en puissance de la branche 8 avec un lot de nouvelles fonctionnalités très intéressantes :
  • La technologie HOT (Heap Only Tuples) ;
  • L'auto-optimisation du processus d'écriture en tâche de fond ;
  • La validation asynchrone ;
  • L'étalement des points de vérification ;
  • Les parcours synchronisés ;
  • La réduction des en-têtes varlena ;
  • La protection du parcours du cache L2 ;
  • L'assignation paresseuse des XID.
Mais les administrateurs et développeurs ne seront pas non plus en reste avec notamment les nouvelles fonctionnalités suivantes :
  • La journalisation applicative au format CSV ;
  • SQL/XML ;
  • Le support de MS Visual C++ ;
  • La gestion des ENUM ;
  • La recherche textuelle intégrée ;
  • SSPI & GSSAPI ;
  • Les tableaux de types composés ;
  • pg_standby.
Bien entendu, les fonctionnalités citées ne sont en aucun cas exhaustives. Je vous invite donc à consulter la liste complète des nouvelles fonctionnalités ainsi que la matrice des fonctionnalités et les notes de versions pour avoir une idées des 300 modifications qui ont eu lieu dans cette version. Pour l'utiliser dès aujourd'hui :Plus de 200 contributeurs de ce projet libre par excellence sont heureux et soulagés de livrer cette superbe version après 15 mois de travail ! Profitez vite des nouvelles fonctionnalités et performances !

Aller plus loin

  • # Mysql c'est mieux

    Posté par  . Évalué à -10.

    moins lourd, et surtout, possibilité d'utiliser des clusters.

    • [^] # Re: Mysql c'est mieux

      Posté par  . Évalué à -8.

      Mettre dans ce fil les raisons pour lesquelles vous préférez mysql

    • [^] # Re: Mysql c'est mieux

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

      Quand on voit l'historique des deux, je sais à quel système je confierai des données vitales (son nom commence par P)...

    • [^] # Re: Mysql c'est mieux

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

      Ce qui est vraiment mieux c'est d'avoir le choix...

      Nous utilisons des bases MySQL et des bases Postgres, chacune pour des projets différents et des fonctionnalités différentes des bases. (MySQL par exemple ne gère pas l'héritage de table)

      Axel

      • [^] # Re: Mysql c'est mieux

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

        Idem pour moi. Je vais utiliser Postgre quand je vais lui demander des requêtes très complexes, genre des divisions relationnelles ou des imbrications à quatre niveau. J'ai fait tout un système d'extractions de tableau de bord assez complexe avec la base d'une gestion de production, je ne l'aurai jamais confié à Mysql.



        Sinon, pour faire select nom from client where id = 34, là mysql est souvent plus indiqué.

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

  • # postgresql c'est mieux

    Posté par  . Évalué à 2.

    parce que c'est "la base de données libre la plus avancée au monde."

    Mettre dans ce fil les raisons pour lesquelles vous pensez que postgresql est mieux.

    • [^] # Re: postgresql c'est mieux

      Posté par  . Évalué à 10.

      1/ Grande qualité de code, élégance, sérieux, pas de bidouille
      3/ Libre
      2/ Pérennité et intégrité des données
      4/ Richesse fonctionnelle
      5/ Trés extensible
      6/ Communauté
      ...

      • [^] # Re: postgresql c'est mieux

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

        7/ Contraintes d'intégrité
        8/ Procédures et fonctions stockées.
        ...

        • [^] # Re: postgresql c'est mieux

          Posté par  (site web personnel, Mastodon) . Évalué à 5.

          ça existe dans mysql ça....

          • [^] # Re: postgresql c'est mieux

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

            Je ne crois pas que les procédures stockées soient aussi ancienne dans MySQL que dans Postgres...

            Quand on a fait un choix de DB, qu'on a développé des applis dessus avec des procédures stockées, on va pas changé dès que la concurrence se met "à niveau"...

            Et au niveau de ces procédures stockées, je ne crois pas que MySQL gère autant/les mêmes langages que PG.

            Axel

          • [^] # Re: postgresql c'est mieux

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

            Pas d'accord pour les contraintes d'intégrité. Ca existe en utilisant *certains* moteurs de stockage de MySQL, ça n'existe pas dans MySQL.
            C'est très très différent parce que certaines autres fonctionnalités de MySQL excluent le choix de ces moteurs et ne permettent donc pas d'avoir les contraintes d'intégrité.
            Dans le cas des contraintes d'intégrité de type foreign keys, ça te restreint à InnoDB et donc :
            - tu n'as plus les count(*) instantanés magiques à la MyISAM,
            - tu ne peux pas faire de multi-master,
            - probablement d'autres trucs.
            Bref, tu peux effectivement avoir des contraintes d'intégrité en utilisant certains moteurs mais ça te coupe de fonctionnalités proposées par d'autres. Le jour où cela sera supporté par tous les moteurs et ne sera pas discriminant, ce sera effectivement présent dans MySQL.
            Ce serait intéressant d'avoir une matrice des fonctionnalités présentes dans chaque moteur pour bien voir le OU et pas une liste de fonctionnalités globales qui masque la réalité en faisant un ET.

            • [^] # Re: postgresql c'est mieux

              Posté par  . Évalué à 10.

              Ce serait intéressant d'avoir une matrice des fonctionnalités présentes dans chaque moteur pour bien voir le OU et pas une liste de fonctionnalités globales qui masque la réalité en faisant un ET.

              http://dev.mysql.com/doc/refman/5.1/en/storage-engine-choosi(...)

              • [^] # Re: postgresql c'est mieux

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

                Merci pour ce lien. Il n'est pas dans le manuel de la 5.0 (la version stable actuelle) ce tableau, par contre, j'ai l'impression. C'est un chouette ajout.

                • [^] # Re: postgresql c'est mieux

                  Posté par  . Évalué à 10.

                  Oui c'est intéressant comme tableau.

                  On se rend compte que si avec MySql on veut pouvoir utiliser les transactions, il est impossible de faire de la recherche Full Text.

                  Si on veut pouvoir utiliser les index HASH, on ne peut pas utiliser les FOREIGN KEY...

                  Enfin bref, ça fait vraiment pas sérieux comme base transactionnelle. On sent bien que c'est une base de données qui est faite plus pour les site web, et non pas pour les mises à jour massives...

                  Dans PostgreSQL ça fait belle lurette qu'il y a les transactions, les triggers, les contraintes diverses dont les clefs étrangères, les index B-tree, Hash, GiST et GIN, le FullText search, les triggers, procédures stockées etc.

                  • [^] # Re: postgresql c'est mieux (pas toujours)

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

                    Oui, mais il ne fait pas une chose : être rapide sur des petites requetes, point fort qui a fait le succès qu'on connait de MySQL.
                    Alors bon, OK PostGreSQL c'est génial, ca fait plein de chose.
                    Mais c'est pas la peine de sous-entendre que MySQL est de la merde.
                    Il n'a pas les même priorités, c'est tout.

                    • [^] # Re: postgresql c'est mieux (pas toujours)

                      Posté par  . Évalué à 2.

                      Je vois souvent cet argument en faveur de MySQL (ou en défaveur des autres), mais techniquement cela est dû à quoi ?
                      si quelqu'un a des liens, des infos, des explications concernant cet avantage de MySQL sur les autres, ma curiosité lui en sera gré :-)

                      • [^] # Re: postgresql c'est mieux (pas toujours)

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

                        J'ai pas de liens, j'ai juste vu des tests de perfs par ci et par la, surtout pour des hébergeurs qui savent très bien que leur clients veulent juste faire un blog-like pas très demandeur en intégrité tout ça...

                        Pour la raison, je me doute que c'est justement parce que MySQL fait l'impasse sur certains calculs d'integrité (ou autre, je ne suis pas assez expert) consommatrices de CPU

            • [^] # Re: postgresql c'est mieux

              Posté par  . Évalué à 7.

              Oui, et puis il y a ça aussi :

              For other storage engines, MySQL Server parses and ignores the FOREIGN KEY and REFERENCES syntax in CREATE TABLE statements. The CHECK clause is parsed but ignored by all storage engines. See Section 1.8.5.4, “Foreign Keys”.
              (cf. http://dev.mysql.com/doc/refman/5.1/en/create-table.html)

              Non seulement MySQL laisse passer des choses sans les faires, mais ne supporte pas non plus la clause CHECK.

              Donc bon...support des contraintes hein...

              PostgreSQL lui, en plus de bien entendu supporter CHECK, remet le couvert en proposant les domaines et la céation de type personnalisé qui peuvent encore enfoncer le clou de l'intégrité...

              Bon, allé, je sais que la plupart d'entre vous ont déjà vu passé ce document ici, mais je le recolle tout de même : "Pourquoi préférer PostgreSQL à MySQL : comparatif de fiabilité et de rapidité en 2007" http://www.postgresqlfr.org/?q=node/1432

          • [^] # Re: postgresql c'est mieux

            Posté par  . Évalué à 4.

            Des triggers qui ne se déclenchent pas si on fait des updates via l'API, je n'appelle pas cela des triggers....

    • [^] # Re: postgresql c'est mieux

      Posté par  . Évalué à 10.

      parce qu'il ne me laisse pas insérer 30 Février 2008 dans un champ date.

      parce qu'il vise avant tout la stabilité, la fiabilité et la cohérence des données.

      parce que ses performances sont nickel.

      parce qu'un éléphant ça sait compter, et on peut compter sur lui.

      parce que les mailing lists.

      parce que Tom Lane.

      parce que MySQL et PostgreSQL n'ont en commun que le fait d'être des logiciels libres, mais qu'ils ne jouent pas dans la même catégorie.

      parce que à l'opposé de MySQL qui est un logiciel libre, PostgreSQL est un projet libre.

      parce que pas un plantage et pas une seule perte de données en 3 ans.

      • [^] # Re: postgresql c'est mieux

        Posté par  . Évalué à 10.

        Parce que PostgreSQL respecte au mieux le standard SQL.

        Parce que PostgreSQL est simple. Avec MySQL on peut s'arracher les cheveux pour des conneries (les dates sont un bon exemple). Avec MySQL on peut pisser des lignes de code pour compenser ses faiblesses.

        Parce que la documentation est superbe.

        Parce que les outils d'administrations sont parfaits.

      • [^] # Re: postgresql c'est mieux

        Posté par  . Évalué à 8.

        > parce que pas un plantage et pas une seule perte de données en 3 ans.

        Pour l'anectode, et confirmer que les outils d'administration de PostgreSQL sont très sérieux, j'avais une base de données sous PostgreSQL 7.2. Base de données qui avait des fonctions embarqués, des rules, triggers et "large object". Je suis passé à PostgreSQL 8.2 les doigts dans le nez (je veux bien reconnaitre que j'ai eu un peu chance). Récupération des dumps de l'ancien base (fait tout les jours via un cron), création des comptes utilisateurs, et envois des dumps dans le nouveau server PostgreSQL (pas si nouveau car en "production" depuis un moment). Pg_dump/pg_restore a géré tout ce qui est compatibilité. Tout marche nickel comme avant.

      • [^] # Re: postgresql c'est mieux

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

        > parce que pas un plantage et pas une seule perte de données en 3 ans.

        Ah, j'ai mieux, 8 ans.

    • [^] # Re: postgresql c'est mieux

      Posté par  . Évalué à 7.

      Parce que PostGIS marche moins bien sur MySQL ou Firebird (très bien, cela dit, Firebird)

    • [^] # Re: postgresql c'est mieux

      Posté par  . Évalué à 10.

      Et parce que ça fait chier les fanboys de MySQL et ça, ça n'a pas de prix.

    • [^] # Re: postgresql c'est mieux

      Posté par  (site web personnel, Mastodon) . Évalué à 5.

      En dehors d'un petit site perso, je n'ai jamais vraiment fait du SQL, et ne pourrais donc comparer ces deux SGBD. Mais à vous entendre (et c'est loin d'être la première fois), PostgreSQL semble réellement être supérieur en tout point à MySQL. Que ce dernier soit plus facile d'accès, on comprend le succès de LAMP, mais dans le cas de sites suffisamment professionnels et à très forte charge tel que Wikipédia, pourquoi ont ils fait le choix de MySQL ?

    • [^] # Re: postgresql c'est mieux

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

      Pour tout ce qui est cité ci dessus, et pour l'extension spatiale PostGIS, qui permet de stocker et de traiter de l'information géographique de manière simple et (très) efficace.

      On peut citer l'IGN et plus de 20To de données dans PostGIS pour le geoportail.

      On peut aussi reciter pgAdmin III qui est vraiment un plaisir à utiliser.

      • [^] # Re: postgresql c'est mieux

        Posté par  . Évalué à 3.

        J'avais commencé par utiliser PgAdmin3, mais il a fini par me "saouler grave" (sous Windows, en tous cas). Je me suis remis à phppgadmin, et finalement c'est plutôt pas mal.

        Mais effectivement, le choix c'est Bien (tm). Et PostGIS aussi ;)

        • [^] # Re: postgresql c'est mieux

          Posté par  . Évalué à 6.

          A ce propos, la nouvelle version de phpPgAdmin devrait bien pointer le bout de son nez.

          Nous sommes pour le moment en beta1, le projet avance, malgrès une équipe de développement pas trés étoffée et plutôt surchargée par ses a-cotés.

          Bref, tirez la version CVS de PPA, et testez là !!

          Pour ce faire:

          $ cvs -d:pserver:anonymous@phppgadmin.cvs.sourceforge.net:/cvsroot/phppgadmin login

          $ cvs -z3 -d:pserver:anonymous@phppgadmin.cvs.sourceforge.net:/cvsroot/phppgadmin co -P webdb -d phpPgAdmin

          Contributeurs bien venu, rdv sur les ml et sur freenode #phppgadmin

      • [^] # Re: postgresql c'est mieux

        Posté par  . Évalué à 1.

        Bonjour,

        quelqu'un aurait une expérience de Toad sur pgsql ?

      • [^] # Re: postgresql c'est mieux

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

        C'est vrai qu'un site qui tombe en rade, à peine on en parle dans le Soir 3, ça fait une référence d'enfer...

    • [^] # Re: postgresql c'est mieux

      Posté par  . Évalué à 4.

      Parce que pgSQL respecte les normes et les standards.

      Parce que pgSQL gère la concurrence d'accès différemment.

  • # Perfs !

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

    J'attends beaucoup des commit asynchrones, j'espère que le bon en avant des perfs est significatif. En tout cas, postgres 8 aura bien évolué et dans le bon sens, vu le parcours depuis la 8.0...
    la 8.2 marquait déjà le progrès au niveau perfs brutes assez impressionant, maintenant avec le support des ENUM (fonctionnalité tellement attendu par les "switchers mysql"), la recherche full text TSearch (encore ces switchers !), et les HOT, postgres s'impose comme un véritable concurrent de poids face à d'autres SGBD proprio (non pas qu'il ne l'était pas avant mais il s'affirme de plus en plus).

  • # Yo

    Posté par  . Évalué à 3.

    Bonne récap mon petit ioio ;)

    J'en profite pour demander si quelqu'un à une experience Samba / postrgre pour un domaine doz à la place de Samba / LDAP. Ca semble interessant mais mal documenté...

    Kaf.

    • [^] # Ploup

      Posté par  . Évalué à 1.

      > Bonne récap mon petit ioio ;)

      Merci mon grand kak^WCoco :)

      > J'en profite pour demander si quelqu'un à une experience Samba / postrgre
      > pour un domaine doz à la place de Samba / LDAP. Ca semble interessant
      > mais mal documenté...

      Oui, malheureusement...Samba a abandonné les backend db et un projet à emergé pour "maintenir" la chose : http://pdbsql.sourceforge.net/

      Mais effectivement la doc et les exemples y sont trés pauvre et pas à jour...

      Il reste toujours un Samba / LDAP / PgSQL qui lui semble un peu mieux documenté :)

    • [^] # Re: Yo

      Posté par  . Évalué à 1.

      euh, question ingénue, mais quel est l'intérêt d'un Samba / Postgre par rapport à un Samba / LDAP?

      • [^] # Re: Yo

        Posté par  . Évalué à 1.

        Virer LDAP ?

        Bon, sinon, à part ça, oui LDAP est utile pour mutualiser des choses et des services comme l'authentification, mais parfois, adns ce dernier cas, PAM peut trés bien suffir aussi pour faire la colle avec une simple base.

        De plus, LDAP reposant sur une base de donnée, pourquoi se priver de virer ce protocol supplémentaire si le SI en question le permet ? Et justement ce pourrait être le cas de Kaf si le module pdbsql était un peu mieux supporté/documenté...

        Mais il faut croire que la norme est à Samba/LDAP depuis les fameux scripts smbldap et pour se rapprocher au mieux d'Active Directory je suppose...

        • [^] # Re: Yo

          Posté par  . Évalué à 1.

          ben ldap a d'autres intérêt par rapport à une bd : un annuaire est censé etre plus efficace en lecture seule, alors qu'une bd est plus conçu dans un sens de lecture/écriture.

          Je ne dis pas que postgresql ne peut pas convenir, je dis que la philosophie derrière est légèrement différente.

          Ensuite LDAP est très souvent utilisé pour l'authentification en entreprise, ce qui peut expliquer son couplement avec samba.


          Question conne :
          Il est très facile de faire des attributs multivalués avec du LDAP. (par exemple : liste des alias de messagerie d'un user).
          Sous postgres, on est obligé de prendre
          - des tableaux ? (c'est sql ou postgres only les tableaux dans postgres ?)
          - de faire une jointure ?
          Ou il y a une autre méthode ?

        • [^] # Re: Yo

          Posté par  . Évalué à 4.

          De plus, LDAP reposant sur une base de donnée, pourquoi se priver de virer ce protocol supplémentaire

          Parce que nombre d'applicatifs causent nativement le LDAP et beaucoup moins causent nativement "ton" schéma de stockage des utilisateurs sur PG?

          • [^] # Re: Yo

            Posté par  . Évalué à 1.

            Tu peux aussi me citer en entier, tu notera que j'avais pourtant bien précisé "si le SI en question le permet" (SI: Système d'Information, au cas où hein)...

            Et puis pas mal d'applications ont des extensions permettant d'authentifier sur une base SQL, nativement en pgsql ou via ODBC par exemple.

            Maintenant, si vous voulez coller du LDAP à tous les étages même dans une entreprise n'en ayant pas le besoin hein...Perso LDAP ne me sort pas encore totalement par la tête...Mais allez en parler à Kaf :)

            • [^] # Re: Yo

              Posté par  . Évalué à 1.

              Tu peux aussi me citer en entier, tu notera que j'avais pourtant bien précisé "si le SI en question le permet" (SI: Système d'Information, au cas où hein)...

              C'est vrai, mais ta précondition avait vraiment des allures de poudre verte... ("citez moi une raison pour ne pas remplacer LDAP par PG, dès lors qu'il n'y a aucune raison pour garder LDAP", en substance).

              Pour la standardisation (de fait) des accès DB en lieu et place de LDAP, c'est vrai que ça commence à venir, mais le moins qu'on puisse est que c'est tout sauf unifié. Pire que LDAP, c'est dire :>

            • [^] # Re: Yo

              Posté par  . Évalué à 1.

              Et puis pas mal d'applications ont des extensions permettant d'authentifier sur une base SQL, nativement en pgsql ou via ODBC par exemple.

              Le "pas mal" est quand même assez vague, et en plus on dépend de la base de donnée. Le gros avantage de LDAP reste quand même son haut niveau d'interropérabilité. J'ai eu pas mal de projets à gérer avec du LDAP (web, messagerie, authent OS,...) et franchement, pour rien au monde je n'aurai mis une base de donnée SQL avec. Avec LDAP, j'ai des schemas standardisés donc pas la peine de se triturer l'esprit pour les attributs. Pour ce qui de se rapprocher d'AD, je rappelle quand même que les authent sur LDAP sont arrivées sur les Unix bien avant AD.
              Et je ne parle même pas des perfs....

              • [^] # Re: Yo

                Posté par  . Évalué à 1.

                J'ai bossé dans une grosse boite ou le nombre de serveurs unix était assez conséquent, et pour déployer massivement les comptes certains ot eu l'idée de faire appel à une solution propriétaire, nécessitant une usine à gaz Java pour fonctionner, avec extraction de données d el'annuaire LDAP pour les injecter dans la base et n tas de trucs bizarre, alors qu'en utilisant l'annuaire LDAP, ça aurait fait la m^^eme chose et ^coûté moins cher.

                • [^] # Re: Yo

                  Posté par  . Évalué à 1.

                  C'est bon, c'est bon, n'en jetez plus, je ne suis pas un anti-LDAP non plus hein...

                  Ceci dit merci à vous pour vos info diverses (histoire de lecture plus efficace et param multi-valeurs), j'ai été me documenter un peu plus là dessus et me suis rendu compte d'une chose qui m'avait *bien* échappée (chkreugneugneu) jusqu'ici : Berckley DB n'est pas une base de données au même sens que les bases SQL bien connues...

                  ..Et là, beaucoup de choses s'expliques du coup :)

                  • [^] # Re: Yo

                    Posté par  . Évalué à 2.

                    C'est bon, c'est bon, n'en jetez plus, je ne suis pas un anti-LDAP non plus hein...

                    Tu réagis mal ....

                  • [^] # Re: Yo

                    Posté par  . Évalué à 5.

                    ioguix, t'es pas tout seul... :)

                    moi non plus je n'aime pas trop LDAP et LDAP j'en reviens franchement. Je bosse dans une université où on a mis en place un annuaire openLDAP pour la gestion des comptes utilisateurs , auth sur un portail web pour accès intranet ( SSO via CAS) et plus spécifiquement la messagerie dont je m'occupe

                    notre SI est basé sur du MySQL (je rentre pas dans le débat MySQL vs Postgres, je reconnais des qualités indéniables à Postgres, mais on a choisi MySQL et on en est très content) et un annuaire LDAP "norme SUPANN" pour ceux qui connaissent (avec 20000 étudiants et 1500 personnels derrière)

                    j'ai eu bien des déboires avec OpenLDAP (sous woody puis sarge), avec des démons slapd qui se cassait la gueule sans raison apparente, ou qui grossissaient grossissaient.

                    Encore très récemment une mauvaise expérience : coupure electrique, le serveur MySQL repars sans problème, le serveur LDAP (sur la meme machine) : HS et faut y aller à coup de db_recover en virant les logs (et en priant) sinon ça plante tjs

                    on parle de performances ? quand je vois la misère (temps de traitement) pour faire des modifications de données online (à chaud) par traitement par lot par rapport à MySQL, même pas la peine... On en est à un point où on supprime et regénère en offline chaque nuit l'annuaire LDAP à partir des bases MySQL, mais de plus en plus notre backend principal devient la base MySQL et non plus l'annuaire LDAP car la confiance dans sa stabilité n'y est plus

                    je vous parle pas non plus du côté penible de la syntaxe en ligne de commande pour faire la moindre modification, suppression avec des dn long comme mon bras. avec une GUI, Vous connaissez surement phpldapadmin, et ben j'essaie meme plus de m'en servir, dès que je clique sur la branche 'people', le sablier tourne, tourne, tourne et tourne encore,

                    Non franchement je suis vacciné de LDAP , j'ai pourtant persévéré mais je suis vacciné et désormais je m'appuie sur un backend MySQL quand je peux

                    auth CAS + MySQL pour le web
                    postfix + courier-imap avec auth MySQL
                    proftpd + MySQL
                    me reste un radius relié au LDAP à transformer en radius + MySQL

                    Effectivement reste plus que Samba qui reste assez lié à LDAP pour de l'auth centralisé mais je me dit qu'avec pam_mysql ou pam_pgsql

                    si qqu'un a déjà mis en place ce genre de choses, samba+pam+bdd (postgres ou mysql) j'suis preneur de liens

                    C'est peut-etre l'avantage de MySQL sur Postgres : une plus grande facilité de connectivité possible (avec souvent des paquets *-mysql sous Debian) avec les outils qui nécessite de l'authentification utilisateurs (postfix, courier, radius, serveurs ftp etc etc)

                    voilà pour mon expérience

                    a+

        • [^] # Re: Yo

          Posté par  . Évalué à 1.

          C'est triste ton point de vue sur LDAP.

  • # 8.4

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

    A noter ce mail concernant la prochaine version (8.4) : http://article.gmane.org/gmane.comp.db.postgresql.devel.gene(...)

    A priori le modèle de développement va changer pour éviter à l'avenir les retards dont à souffert la 8.3.
    Le modèle choisi est celui des périodes de merge (les "commit fest") suivis de périodes de stabilisation/correction.

  • # PostgreSQL oui mais pas tout de suite

    Posté par  (Mastodon) . Évalué à 5.

    En toute honnêteté, j'aime bien PostgreSQL par rapport à MySQL, même si je ne l'ai jamais utilisé vraiment. Mais le fait que ça soit plus proche des standards, juste ça, ça me va. Parce qu'en MySQL, on ne sait jamais si on fait du vrai SQL ou du MySQLisme (pareil que les bashisme vis-à-vis du sh POSIX). Le support des transactions, le support de l'Unicode, le support des clefs étrangères, tout ça, c'est très bien et ça renforce mon opinion par rapport à PostgreSQL.

    Seulement voilà, si on veut l'utiliser avec le driver JDBC [1], ben il manque des choses dont j'aimerais bien me servir. Et on voit sur la TODO liste [2] qu'il manque des trucs comme Statement.getGeneratedKeys qui est fort pratique. Ça donne l'impression que ce n'est pas encore tout à fait abouti. C'est dommage parce que je troquerais bien mon MySQL contre un PostgreSQL. J'ai lu les différents fils de discussion concernant cette fonctionnalité et je ne comprend pas bien les problèmes, pour moi il faut que cette fonction retourne la ou les clefs qui ont été générées par un INSERT, pas plus ni moins. Il n'y a peut-être pas le support dans PostgreSQL pour le faire mais ça serait vraiment une superbe fonctionnalité à ajouter.

    [1] http://jdbc.postgresql.org/
    [2] http://jdbc.postgresql.org/todo.html

    • [^] # Re: PostgreSQL oui mais pas tout de suite

      Posté par  . Évalué à 5.

      Enfin les drivers JDBC ça ne fait pas partie de pgSQL.

      Parce que bon, je ne suis pas sur qu'il y ait une api FORTRAN non plus.

      Le truc "pas encore tout à fait abouti" comme tu dis, c'est le driver JDBC en lui-même, pgSQL n'a aucun problème.

      Et puis bon, utiliser ce genre de fonctionnalités JDBC, c'est un peu du gâchis avec pgSQL. La solution plus élégante (et surtout plus performante) c'est de faire effectuer le traitement que tu veux par une procédure stockée. Et si tu as besoin de récupérer des IDs, c'est ta procédure stockée qui les retourne.

      Le problème de cette nouvelle mode consistant à avoir plein de petits bouts de SQL éparpillés, ventilés, dans du code Java (ou PHP ou n'importe quoi d'autre), c'est d'abord que les performances sont dégueulasses, et ensuite qu'au niveau maintenance ça devient un vrai casse tête.

      Si on modifie un nom de table ou un type de colonne, il faut se cogner tous le code JAVA pour essayer de voir où se trouvent les adhérences.

      Alors que quand tu fais tes traitements par procédure stockée, tu as tous les traitements sous les yeux mutalisés au niveau du serveur, et si tu rejoues les scripts de création de procédure, tu vois celles qui partent en erreur...

      C'est marrant à dire, mais avec cette nouvelle mode de J2E, Struts & co. je vois les gens refaire les mêmes erreurs qu'il y a 15 ans aux débuts du client/serveur avec les premiers NSDK ou PowerBuilder.

      • [^] # Re: PostgreSQL oui mais pas tout de suite

        Posté par  . Évalué à 3.

        Je suis d'accord avec toi, mais souvent la competence applicative n'est pas chez les DBA, qui en plus sont moins nombreux que les développeurs (et plus chers).
        Enfin techniquement, mettre les fonctions applicatives dans les bases de données fini par bouffer de la performance sur la DB et les licenses (ok sur les DB commerciales ...) se paient au nombre de cores utilisés sur le serveur de DB...
        J'ajoute que pour le stockage, multiplier les serveurs de DB coute aussi pas mal de fric.

        Donc que faire ?
        Utiliser la fameuse mode du n-tiers, et mettre un front-end java sur un serveur applicatif pour heberger le code applicatif sous forme de fonctions, publiée en SOAP par exemple.
        Ces fonctions SOAP concentrent les appels aux DB (donc y'en a pas partout dans toutes les applis), le SOAP c'est gratuit (java + tomcat / jboss), et cela permet (comme les proc stockées) de rendre les fonctions disponibles pour toutes les applis de l'entreprise.

        En bonus, SOAP est un protocole normalisé et disponible sur toutes les plateformes, dans tous les langages (pas la peine de déployer des connecteurs JDBC/ODBC/....)

        Mais je suis d'accord avec toi, les proc stockées c'est bien, y'a juste des contrainte en entreprise qui font que d'autres solutions peuvent être préférées.

        • [^] # Re: PostgreSQL oui mais pas tout de suite

          Posté par  (Mastodon) . Évalué à 4.

          je vais répondre aux deux commentaires ci-dessus d'un seul coup.

          Tout d'abord, comme dit PLuG, je suis dans un cas totalement similaire, sauf que s/SOAP/XML-RPC/ mais après, c'est la même chose.

          Moi je ne suis pas un expert SQL, je veux juste faire des trucs ultra-simple, comme le permet JDBC. Après, je fais ma sauce du côté du Java. Et j'aimerais que mon code marche bien avec toutes les DB imaginables, en particuleir PostgreSQL. Alors ça revient un peu à dire qu'il faut se contenter du plus grand commun dénominateur entre toutes les bases (donc prendre les fonctionnalités de MySQL) mais bon, je ne veux pas utiliser JDBC qui permet d'abstraire la DB et ensuite faire du code SQL spécifique à une DB.

          Ensuite, je suis d'accord, c'est pas forcément un problème au niveau PostgreSQL (et même je pense que le problème ne vient pas de là), mais il n'empêche que de nos jours, on utilise rarement une DB directement mais à partir d'API dans ce genre (il y a aussi PDO pour PHP, DBI pour Perl, etc) et qu'il faut également soigner l'implémentation de ces API, ça compte aussi dans l'adoption (c'était l'objet de mon premier post).

      • [^] # Re: PostgreSQL oui mais pas tout de suite

        Posté par  . Évalué à 2.

        « Si on modifie un nom de table ou un type de colonne, il faut se cogner tous le code JAVA pour essayer de voir où se trouvent les adhérences. »

        Les bonnes pratiques de Java consistent à créer des DAO (Data Access Object), qui font partis des recommandations J2EE depuis des lustres http://java.sun.com/blueprints/corej2eepatterns/Patterns/Dat(...) et les frameworks actuels dédiés aux bases comme Hibernate permettent même de rassembler toutes les requêtes dans quelques fichiers XML dédiés aux bases de données.

        Donc non, actuellement la mode J2EE struts & co, les requêtes SQL ne doivent pas être éparpillés dans tout le code.

        Pour PHP, par contre, les bonnes pratiques semblent effectivement lointaines, quand on n'a pas le SQL mélangé avec le HTML, on a de la chance. La lecture du code source de dotclear m'a redonné quelques espoirs.

    • [^] # Re: PostgreSQL oui mais pas tout de suite

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

      Je ne connais pas JDBC ( je bosse avec des DBI Perl).
      Mais il existe une fonctionnalite Postgresql :
      INSERT INTO ... RETERNING ...
      SI ton driver te permet de faire des fetch (ce que je suppose), ca doit fonctionner !

      le lien vers la doc :
      http://docs.postgresqlfr.org/8.3/sql-insert.html

      • [^] # Re: PostgreSQL oui mais pas tout de suite

        Posté par  . Évalué à 3.

        s/reterning/returning

        Cf. la doc, c'est une extension (apparut dans la 8.2 je crois) qui n'est pas recommandée. La méthode plébiscitée consite à faire un 'select nextval(seq)/curval(seq)' où seq est le nom de la séquence utilisée (p.e. nomtable_champ_seq dans le cas d'une déclaration 'serial').

Suivre le flux des commentaires

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