Sortie de PostgreSQL 8.0

Posté par  . Modéré par Jaimé Ragnagna.
Étiquettes :
0
19
jan.
2005
Base de données
La dernière version de PostgreSQL - un système de gestion de bases de données relationnelles - est enfin sortie après cinq « Release Candidates ». Fait remarquable, c'est la première version « serveur » tournant nativement sous MS Windows (sauf versions 9X/ME). Ceci lui permettra sans doute d'accroître encore son expansion dans le monde de l'entreprise.

Au menu des nouveautés :
- serveur Win32 natif ;
- points de sauvegarde ;
- points de récupération dans le temps ;
- tablespaces ;
- amélioration de la gestion des buffers ;
- modification du type de données des colonnes ;
- nouvelle version de plperl ;
- accès en lecture/écriture aux fichiers CSV (valeurs séparées par des virgules). PostreSQL est un système de gestion de base de données objet relationnel sous licence BSD. Il est l'un des plus avancés dans le monde du libre et dispose d'une excellente réputation, notamment en terme de fiabilité. Il supporte SQL92 et SQL99 ainsi que de nombreuses fonctionnalités :
- requêtes complexes ;
- clés étrangères ;
- triggers ;
- vues ;
- transactions/rollbacks ;
- verrouillage par MVCC (MultiVersion Concurrency Control).

PostgreSQL peut par ailleurs être facilement étendu avec des fonctions écrites en C, PL/PgSQL, Perl, Python, Tcl ou Ruby.

Aller plus loin

  • # Spip

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

    Vraiment dommage que Spip ne le supporte pas :-(
    ya bien une version non-officiel de Spip (pgspip), faut esperer qu'il suive ....

    • [^] # Re: Spip

      Posté par  . Évalué à 4.

      Il y a aussi SPIP-Agora qui supporte cette base

  • # Autre news

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

    Cette news donne quelques détails suplémentaires sur PostgreSQL et ce qui tourne autour (PhpPgAdmin, conf postgreSQL au Solution Linux ...)

    http://www.labo-linux.org/index.php?page=news&id=596(...)

  • # Pythie

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

    A l'assaut d'Oracle!

  • # Bonne raison de changer de mySql à PostgreSQL

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

    Cette nouvelle version de PostgreSQL est une très bonne nouvelle. La version win32 peut enfin aller sur les terres des utilisateurs de base, surtout avec pgAdmin 3 comme GUI.

    PostgreSQL est vraiment une bonne base de données, qui mérite bien plus d'adoption que mySql, malheureusement souvent préférée.
    MySql se contente de singer quelques fonctionnalités SQL, a des GUI clickodromes (sous win32 la plupart), et est fournie "en standard" (voir LAMP). Du coup la plupart des gens l'adopte, de la même façon que les utilisateurs de IE l'utilise car c'est sur le poste, et ne se pose aucune question. Les gens sous win32 aiment mySQL. Mais combien de gens sous win32 sont prêts à jurer que Access est une super BDD ?

    Les gens qui disent que mySql "leur suffit" n'ont jamais eu à se plaindre des bugs et des manques techniques de mySql, mais devraient quand même réfléchir pour leurs prochains choix. De plus, PostgreSQL est simple à installer et à configurer, probablement plus simple que mySql, bien que founissant des fonctions plus puissantes à terme.

    MySql n'est libre, cela appartient à MySQL AB Company, qui a un marketing et une propagande supérieurs.

    Pour terminer, les benchmarks récents montre que PostgreSQL monte mieux en charge que mySql, et que les perfs globales sont finalement meilleures avec PostgreSQL.

    • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

      Posté par  . Évalué à 5.

      ok, je comprends,
      mais a qui la faute ? un peu la faute aux FAI, qui ne propose que du mysql, resultat quand on se monte une machine linux on essaye mysql parcequ'on connais : on a fait du PHP avec.

      bien sur ce cas ne represente qu'une partie de la réalité, mais je suis sur à ne pas être le seul. il y a longtemps, j'ai appris le php avec mysql parceque free le permetait, par la suite, j'ai continué et maintenant que j'ai des linux j'utilise du mysql alors qu'il y a d'autre produit.

      De ce pas, je prends la bonne résolution suivante : essayer pgsql :)

      • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

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

        mais a qui la faute ? un peu la faute aux FAI, qui ne propose que du mysql

        Nerim propose une base de données PostgreSQL avec son service de pages personnelles (ainsi que le support MySQL si vous avez une base MySQL ailleurs)

        http://perso.nerim.net/(...)

        • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

          Posté par  . Évalué à 1.

          Cela doit faire peu de temps que c'est en place alors parce que si je me rappelle bien, ils ne proposaient que le client MySQL il n'y a pas si longtemps ?

          Une raison de plus pour essayer ! Merci pour l'info.

          • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

            Posté par  . Évalué à 2.

            elle ne fera pas long feu si elle fout le serveur par terre, je pense :)

            c'est déjà pour ça qu'ils ne proposent pas gd ni l'hébergement de bases mysql (donc out les phpbb et autres horreurs)

          • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

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

            Ca devait faire 2 ans qu'il y avait les 2 clients dans PHP.

            Mais bon, le gros de l'utilisation de postgres chez Nerim, c'est le système d'information (gestion des comptes ADSL et gestion du support). Les 2 appli utilisent Pg comme BDD, avec une mention spéciale a admin.nerim.net qui est programmée en grande partie en PL


            Sinon, pour la préférence des FAI a mettre mysql plutot que Pg, c'est principalement parce que le mutualisé avec Pg, c'est pas aussi flexible que MySQL a administrer (et je suis bien placé pour le savoir aussi, c'est moi qui me suis tapé la mise en place des scripts de génération de compte Pg chez Nerim).
            En gros, le seul truc a peu pres viable que j'ai trouvé, c'est le 1 base par user avec nom de la base = login. Mais meme comme ca, les clients peuvent connaitre le nom de toutes les bases du serveur, ce qui n'est quand meme pas top.

            Mysql est quand meme largement plus fin dans sa conf de sécurité

            (ps : ceci n'est pas de la pub déguisée, je ne bosse plus pour Nerim depuis 3 mois)

    • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

      Posté par  . Évalué à 10.

      Cette nouvelle version de PostgreSQL est une très bonne nouvelle. La version win32 peut enfin aller sur les terres des utilisateurs de base, surtout avec pgAdmin 3 comme GUI.

      Ouaip

      MySql se contente de singer quelques fonctionnalités SQL

      ...qui suffisent à 80% des applis web existantes.

      a des GUI clickodromes (sous win32 la plupart)

      Qui ne sont pas du fait de MySQL AB, mais d'utilisateurs/groupes tiers. Tu utilises une GUI pour gérer tes BDs ? psql te suffit pas ?

      Les gens qui disent que mySql "leur suffit" n'ont jamais eu à se plaindre des bugs et des manques techniques de mySql,

      C'est bizarre, j'entends d'ici les DBA Oracle dirent la même chose sur PostgreSQL...

      MySql n'est libre
      Hou la! Dual Licence dont la GPL.

      MySQL AB ... qui a un marketing et une propagande supérieurs.
      RedHat installe systèmatiquement PostrgeSQL

      La news évitait le troll. Heureusement que tu étais là pour le réveiller

      • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

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

        Et serieusement, dans quel cas est-il plus interressant pour un site web de prendre MySQL ou Postresql?

        • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

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

          Il existe un certain nombre de CMS qui ne fonctionnement qu'avec MySQL, alors à moins de reprendre le PHP (ouais, en plus, c'est souvent du PHP :), il faudra adopter MySQL.
          La différence entre les deux SGBD peut vraiment s'exprimer dans le cas de situations un peu complexes : si MySQL est un SGBD "rapide" (OK, on pourrait parler de ça pendant des heures), PostgreSQL sera plus performant (voire sera tout court) pour des applications nécessitant des requêtes complexes, une gestion de l'information géographique, une bonne résistance à la charge, de la "haute disponibilité", etc.

          Et comme postgreSQL marche aussi très bien pour répondre à des besoins simples, et bien, pourquoi ne pas l'utiliser tout le temps ?

          • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

            Posté par  . Évalué à 9.

            Et comme postgreSQL marche aussi très bien pour répondre à des besoins simples, et bien, pourquoi ne pas l'utiliser tout le temps ?

            parce qu'on est en 2005 et qu'ils ont donc mis au bas mot 5 ans à sortir une version native pour une plateforme raisonnablement décente (Windows 2000 et successeurs).

            pendant ce temps, MySQL était utilisable par toto en local sur son Apache/PHP/Mysql sous Windows 95 et autres, et une fois que son site de trois pages marchait chez lui, il l'uploadait sur son compte du type pages perso de Free. car en plus, c'était portable à ses yeux.

            résultat, il y a tout un existant qui marche souvent déjà bien depuis des années et il n'y a souvent strictement aucune raison d'y toucher.

            ça gène certains trolleurs et autres débiles moyens qui se pavanent en répandant des torrents de vomi sur ce qui a rendu des services à des millions de personnes ? il fallait sortir quelque chose il y 5 ans.





            ce "burn all your mySQL", ça me rappelle les "burn all your GIF". résultat, le gif est encore là et bien là.

            • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

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

              > pour une plateforme raisonnablement décente (Windows 2000 et
              > successeurs).

              voulais tu écrire "relativement récente" ?

              parceque le "relativement récente" je te l'aurais accordé, mais le "relativement décente" j'ai un peu de mal...

              tant sur le plan de la fiabilité que de l'éthique, windows 2000 et successeurs sont complètement indécents.

              • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

                Posté par  . Évalué à 1.

                j'ai du mal à cerner comment un OS peut être indécent sur le plan de l'éthique.

                je veux bien croire que les machines sous Windows sont souvent hantées par toute une faune variée et souvent dangereuse pour leurs utilisateurs comme pour les autres machines quand elles se mettent à vomir des paquets de spam ou de DDoS, mais aux dernières nouvelles, ce ne sont pas encore des IA, donc va plutot régler tes soucis d'éthique avec l'éditeur de ce produit. ou mieux, ne perds pas de temps et fuis-le.

            • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

              Posté par  . Évalué à 3.

              Sous Windows, PostgreSQL n'était pas utilisable il y a 5 ans c'est exact, mais sous Linux je m'en suis servi dès 2000 vu ses capacités qui étaient nettement supérieures (à l'époque, des trucs un peu basiques du SQL n'existaient pas sous MySQL).

              J'ai toujours regretté que MySQL ait autant de succès alors que PostgreSQL ne décollait pas plus, alors qu'il est simple à installer et à utiliser, et que c'est depuis le début une vraie base de données relationnelle avec contrôle d'intégrité.

              Cela dit je suis bien d'accord que si MySQL rend des services, qu'on l'utilise et tant mieux. Je crains cependant que certaines personnes, ignorant qu'il existe plus puissant, fassent de la gestion de données dans le code applicatif au lieu de confier la logique à la base de données.

              ce "burn all your mySQL", ça me rappelle les "burn all your GIF". résultat, le gif est encore là et bien là.

              En l'occurrence, le PNG n'a que des avantages sur le GIF (plus léger, plus de possibilités), je ne vois aucune raison de continuer à l'utiliser. Là aussi je suis perplexe quand je vois qu'il en reste autant. :-(

        • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

          Posté par  . Évalué à 6.

          PostgreSQL devient intéressant si :

          - tu as des gros volumes de données, notamment en écriture,
          - tu as des traitements complexes qui nécessitent des procédures stockées (enfin, "nécessitent", c'est un grand mot, disons simplement que c'est mieux comme ça),
          - tu as besoin d'offrir un service permanent -> utilisation intensive des points de sauvegarde.

          C'est clair que de très grosses applications (cf. Wikipedia) peuvent néanmoins se "contenter" de MySQL. Après, je pense que c'est plus de travail de gérer une "hénaurme" base MySQL que la même en PostgreSQL, car ce dernier offre plus d'aides à l'administrateur.

          Et j'en profite pour rappeler qu'il n'y a pas que PostgreSQL et MySQL dans les bases de données libres. Il ne faut pas oublier, entre autres, McKoi, Firebird, Ingres, Firebird, MaxDB (ex SAPdb), Firebird, HSQL, Firebird, sqlite, etc...

          Y'en a une que j'aime beaucoup. Je vous laisse deviner...

          • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

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

            Moi personnellement je développe un site web dynamique, avec peu de besoins en base de données. Au boulot j'utilise Postgres, et je connais et j'apprécie les contraintes. Les procédures stockées sont plutôt nécessaires pour des utilisations plus poussées comme tu le soulignes, et je n'en ai pas besoin, par contre je trouve les contraintes vraiment indispensables pour avoir une base à peu près clean, que le nombre de tables et les traitements soient réduits ou non. Résultat, en apprennant que les contraintes ne sont pas disponibles avec MySQL à moins d'utiliser InnoDB sur la version 3 (donc vraiment pas dispo sur woody), j'ai été "obligé" d'opter pour Postgres.

            Je ne sais pas comment les utilisateurs de longue date de mysql font pour créer des tables qui se référencent entre elles sans utiliser de contraintes, ça me semble le minimum vital pour pas faire du grand n'importe quoi... Un petit exemple pour fixer les idées :

            CREATE TABLE alerts (
                 uid SERIAL,
                 user_uid INTEGER NOT NULL,
                 item_uid INTEGER NOT NULL,

                 CONSTRAINT pk_alerts PRIMARY KEY(uid),
                 CONSTRAINT un_alerts_user_item UNIQUE(user_uid, item_uid),
                 CONSTRAINT fk_alerts_user FOREIGN KEY(user_uid) REFERENCES users(uid),
                 CONSTRAINT fk_alerts_item FOREIGN KEY(item_uid) REFERENCES items(uid)
            );

            • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

              Posté par  . Évalué à 2.

              Les intégrités référentielles entre tables peuvent très bien être présentes dans les schéma des tables sans être gérées par le SGBD.
              Dans ce cas-là (MySQL tables MyIsam par exemple) c'est l'application qui contrôle et assume la cohérence des données avec évidemment les risques que cela engendre...

          • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

            Posté par  . Évalué à 4.

            > PostgreSQL devient intéressant si :
            >
            > - tu as des gros volumes de données, notamment en écriture,
            > ...


            Ça m'agace toujours ce type d'argument.
            Et si je disait :
            Linux devient intéressant si :
            - tu veux du lvm
            - tu veux faire des scripts shell avancé
            - tu as un système multi-cpu
            - etc
            sinon tu ferais mieux de rester sous MS-DOS.

            Comme si le "moins disant technique" est parfois un plus.
            Si tu utilises PostgreSQL comme MySQL, c'est grosso-modo la même chose. Par contre, énorme différence, si tu as besoin de language embarqué tu peux avec PostgreSQL, si tu as besoin de transaction multi-table tu peux avec PostgreSQL, etc...

            C'est comme avec Linux. Si tu veux passer à un système multi-cpu, lvm, etc tu peux avec linux. Quand tu n'utilise pas smp et lvm car tu n'en a pas besoin, smp et lvm ne te dérange pas.

            Je ne vois pas pourquoi ne pas fournir "nativement" une fonctionnalité est un plus par rapport à un système qui l'a fournie mais qui ne te dérange pas si tu ne l'utilise pas.

            • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

              Posté par  . Évalué à 1.

              MandrakeLinux devient interessant si tu utilises le Club.

              oops ! c'est ton texte.

            • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

              Posté par  . Évalué à 3.

              Il y a au moins deux personnes qui préfèrent DOS à Linux ou à n'importequoi d'autre :
              http://www.milec.com/pres/whydos.htm(...)


              La deuxième c'est une chaine de motels bas de gamme aux USA qui a un personnel tellement bas de gamme (ou démotivé selon le point de vue) que leurs postes informatiques utilisent un vieu logiciel de gestion hotelière sous DOS avec le minimum vital de fonctionnalités.

              Donc oui, si on n'a pas besoin de toutes les avancées technologiques de ces dernières années, DOS est préférable à Linux, l'argument tient parfaitement la route.

              BeOS le faisait il y a 20 ans !

              • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

                Posté par  . Évalué à 2.

                Tu es en train de dire que si tu n'as pas l'outil informatique avec les technos top fashion du moment tu es un gros naze ? Si l'outil fonctionne et repond au besoin, quel est l'interet de le redevelopper en n-tiers/xml/pouet-pouet-coin-coin ?

                D'ailleurs, ta banque utilise probablement encore des programmes en cobol, ton loueur de dvd utilise un logiciel sous DOS, ....

              • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

                Posté par  . Évalué à 4.

                La deuxième c'est une chaine de motels bas de gamme aux USA qui a un personnel tellement bas de gamme (ou démotivé selon le point de vue) que leurs postes informatiques utilisent un vieu logiciel de gestion hotelière sous DOS avec le minimum vital de fonctionnalités.

                Avant, les caisses étaient en mode texte et les gars faisaient marcher le truc avec les flèches, tab et le reste du clavier.
                C'était sans doute bien plus facile et bien plus rapide.

                Maintenant, dans certains magazins, tu vois le mec prendre sa souris et cliquer sur 200 boutons et faire une tête pas possible parce qu'il n'arrive pas à faire ce qu'il veut.

                Franchement, je ne sais pas si dans ce cadre là ils n'ont pas raison de garder leur vieux système... pour preuve, dans les grandes surfaces, il n'y a toujours pas de souris... et les écrans, si ils sont pleins de couleurs n'ont pas beaucoup changés...

                • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

                  Posté par  . Évalué à 5.

                  Les caisses des Supermarchés Sainsbury's (UK) ont des écrans tactiles. Une fois j'ai regardé comment ils s'en servaient, c'est impressionnant d'efficacité. Je suis persuadé qu'en terme de formation des utilisateurs ce doit être simplissime.

                  La technologie appliquée à bon escient apporte toujours un gain. C'est mon avis...

                  Bon, ok, ça n'a rien à voir avec PgSql ----> []

                  • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

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

                    Oui, et chez Total-Elf et chez Shell (FR) aussi, ils ont des écrans tactiles (et des souris/claviers pour d'autres trucs que l'exploitation courante).

                    Idem chez Pizza Del Arte / Bistrot Gaulois / Mc Do', etc...

                    Par contre, je suis bien placé pour te dire que la formation n'a pas été si simple que ça...

          • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

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

            Oui, bonne route à PostgreSQL

            Mais c'est vrai qu'au niveau multi plateforme Firebird à de l'avance.
            D'ailleurs, une étude de Evans Data Corporation note le fait que Firebird progresse énormément. cf http://www.evansdata.com/n2/pr/releases/EDCDB05_01.shtml et
            http://www.evansdata.com/n2/surveys/database/2005_1/db_05_1_xmp1.shtml

            Tant mieux que PostgreSQL et Firebird gagnent en crédibilité et présence, il y en a marre de l'uzine à gaz Oracle vendue à prix d'or et quasiment toujours sous utilisée ou de MsSQL .
            Firebird est vraiment opens-source et n'appartient à personne, ça aussi c'est important.


            Au passage, j'espère que l'install de PostgreSQL sous win aura progressée, parce que la première RC était une vrai galère :(

          • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

            Posté par  . Évalué à 2.

            Thunderfox ?

        • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

          Posté par  . Évalué à 4.

          (...) dans quel cas est-il plus interressant pour un site web de prendre MySQL ou Postresql?
          J'étais débutant (et stagiaire) en bases de données il y a 4 ans, et j'ai trouvé un pack (EasyPHP) qui intégrait une solution mySQL. En quelques dizaines de minutes, le serveur apache était installé avec PHP et mySQL configurés. Quelques clicks plus tard, ma premiere table etait créée... Ce qui est important pour les débutants ca n'est pas de gérer les triggers, la réplication, ou quoi que ce soit... c'est pas non plus de militer pour une solution. Donc, je dirais... si l'un des systemes permet de parvenir en 1 heure maximum (pour un débutant) à l'objectif souhaité, peu importe qui a développé le système.

          Une personne déjà compétente sera à même d'évaluer ses contraintes pour choisir une solution, et inversement, les limites propres a chaque systeme ne s'appliqueront dans la plupart des cas, qu'à des personnes qui ont déjà poussé assez loin leur système.

          • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

            Posté par  . Évalué à 2.

            > ca n'est pas de gérer les triggers, la réplication, ou quoi que ce soit...

            Si tu n'as pas besoin de "triggers, la réplication, ou quoi que ce soit..." tu n'as pas à le gerer.

            Linux fournit raid, mais si tu n'utilises pas raid, tu n'as pas à le gérer.

            > si l'un des systemes permet de parvenir en 1 heure maximum (pour un débutant) à l'objectif souhaité

            Certe. Mais un gestionnaire de base de donnée, ce n'est pas que l'installation (loin de là). Tu peux passer des plombes avec mysql si tu veux faire du contrôle d'intégrité ou si tu veux jouer avec les dates.

            • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

              Posté par  . Évalué à 8.

              Mais un gestionnaire de base de donnée, ce n'est pas que l'installation (loin de là). Tu peux passer des plombes avec mysql si tu veux faire du contrôle d'intégrité ou si tu veux jouer avec les dates.
              Sans doute... mais justement, ce que je pense c'est que la réputation de mySQL s'est faite surtout grâce à son accessibilité par des débutants, et que les débutants ne vont pas faire de controle d'intégrité, ne vont pas jouer avec les dates, ne vont meme pas lire la doc, etc... en tout cas au début. Comme dans mon cas personnel, adopter mySQL à l'époque n'est pas le fruit d'une intense réflexion parmi toutes les solutions disponibles. Une solution me permettait d'installer en 3 coups de cuillère à pot le serveur et le SGBD sans que j'aie besoin de savoir ce qu'il y avait dedans. Ensuite, je tapais 3 lignes de code PHP, un "SELECT" en SQL et là.... magie! j'avais une "page web dynamique". C'est super con, mais mon choix a été fait comme ca, parce que le but était de "faire quelque chose qui marche", non pas de "faire quelque chose qui marche de facon optimale".

              • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

                Posté par  . Évalué à 1.

                > ce que je pense c'est que la réputation de mySQL s'est faite surtout grâce à son accessibilité par des débutants, et que les débutants ne vont pas faire de controle d'intégrité, ne vont pas jouer avec les dates, ne vont meme pas lire la doc, etc...

                +1 :-)

                Mais bon installer postgresql avec php est trivial.
                # rpm -i ....
                # chkconfig postgresql on
                # service postgresql start
                # su -l -c "createuser ... user" postgres
                # su -l -c "createdb ...-O user db" postgres

                Et voilà.

                > Ensuite, je tapais 3 lignes de code PHP, un "SELECT" en SQL et là.... magie! j'avais une "page web dynamique".

                Idem avec PostgreSQL.

                MySQL a/avait deux points forts qui ont aidé "massivement" sa diffusion :
                - disponibilité sous Windows
                - disponibilité chez les FAI

                • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

                  Posté par  . Évalué à 3.

                  Mais bon installer postgresql avec php est trivial.
                  # rpm -i ....
                  # chkconfig postgresql on
                  # service postgresql start
                  # su -l -c "createuser ... user" postgres
                  # su -l -c "createdb ...-O user db" postgres

                  Trop compliqué! vraiment!! ca nécessite de connaitre quelques commandes en shell. Sous windows, tu lances l'executable par un double-click, et puis tu réponds OK chaque fois que l'installeur te pose une question.

                  Pour la disponibilité sous windows, je suis tout a fait d'accord.

                  Pour la disponibilité chez les FAI, tu veux parler des hébergeurs de sites en general, sans doute? oui, c'est vrai aussi que ca a joué. Et pour enfoncer le clou, il y a eu les forums phpBB et IPB qui ont sans doute profité d'une renommée déjà assez large de mySQL pour le démocratiser complètement.

              • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

                Posté par  . Évalué à 1.

                la réputation de mySQL s'est faite surtout grâce à son accessibilité par des débutants

                Non, je ne crois pas. La popularité de MySQL est venue des FAI qui le proposait en standard avec PHP.

                Mais pourquoi les FAI ont proposé mysql ? j'ai entendu que c'était pour sa faible consommation cpu (pas de tests d'intégrité, pas de...).

                Je ne sais pas si c'est vrai, mais Pg permet des choses aux utilisateurs comme les contraintes etc. qui peuvent, dans certains cas augmenter les temps de calculs...

                • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

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

                  L'optique de Mysql est aussi bien differente de celle de Postgres. Mysql privilégie les performances alors que Postgres privilégie l'intégrité des données. Ainsi, le paramétrage par défaut de Mysql est d'écrire les données sur le disque sans forcer l'écriture et de laisser le sync système faire l'écriture (très souvent de l'ordre de 30s) alors que Postgres fait un sync pour chaque transaction effectuée afin d'assurer l'application appelante que l'écriture a été faite. Les performances s'en ressentent ainsi que la charge système. Magiquement, quand on supprime l'écriture forcée via fsync, Postgres est très proche de Mysql en performance pour ne pas dire plus. Maintenant, posez la question à un administrateur DB ce qu'il préfère entre la performance et l'intégrité des données ;-) Pour un FAI, l'optique est toute différente.

          • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

            Posté par  . Évalué à 5.

            Le choix entre Pgsql et MySQL est sans doute moins une question d'appropriation a un projet Web en general.
            Est-ce que c'est un projet perenne ? Est-ce qu'on maitrise la plateforme d'hebergement (MySQL est bien plus couremment offert) ? Est ce que on a des donnees tres structurees ou deux listes toutes betes a stocker ? Est ce que les devs sur le projets ont l'habitude d'un environnement plus que l'autre ? Est-ce que les fonctionnalites specifiques d'une des deux bases reponds a un probleme du projet...... Bref le choix est sans doute tres lie au contexte.

            Il se pose aussi un autre probleme pour la popularite de PgSQL, l'utilisation correcte(au sens de "traditionnelle") du SQL et des SGBDR n'est pas un truc qui s'invente.

            Les normalisations, les regles de l'algebre relationnel sont des trucs que le "debutant" utilisera ex-nihilo.

            Il en découle que MySQL est parfait pour l'utilisation de base de quelqu'un ne connaissant pas bien le SQL.
            On va se retrouver avec une serie de boucles de parcours de SELECT table par table qui a la limite pourraient etre faits sur un Berkeley DB.

            Typiquement, l'usage du SQL pour faire le boulot plutot coté serveur que le code coté client sera le fait de developpeurs ayant eu une formation au informatique "formelle", alors que beaucoup de dev PHP/MySQL sont des autodidactes.

            De plus, mettre de la logique coté base a beaucoup de sens si on concoit une application structurée, avec eventuellement de multiples clients (lourd, web ...) tapant dans la base, mais si on est dans le cadre d'un formulaire web rapido, le plus important est sans doute le temps passé par le développeur.

            Bref, j'ai l'impression que MySQL est plus populaire parceque beaucoup de gens sont venu au dev ces dernieres annees par le PHP/MySQL et n'ont pas eu a trop ressentir le besoin de base "lourde" typique de developpements plus formels.

            • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

              Posté par  . Évalué à 1.

              > Il se pose aussi un autre probleme pour la popularite de PgSQL, l'utilisation correcte(au sens de "traditionnelle") du SQL et des SGBDR n'est pas un truc qui s'invente.

              Tu peux aussi utilise PgSQL comme un porc "ala mysql". PsSQL ne t'impose pas l'excellence.

              • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

                Posté par  . Évalué à 4.

                Tu peux aussi utilise PgSQL comme un porc (...)
                Ca marche très bien, d'ailleurs!!! gnark gnark gnark!!! Si l'environnement est dimensionné très largement, il arrive (même si c'est pas très vertueux, tout ca!!) qu'on ne normalise pas une BDD dont les données ont pourtant des interdépendances... "il faudra juste faire gaffe au niveau applicatif, mais on a pas de temps à perdre à faire les choses proprement" (retranscription de mes directives de travail dans mon précédent boulot)

                Bon, enfin... dans le domaine professionnel, je crois quand même plus constructif de faire les choses proprement dès le début. Mais ce n'est malheureusement pas toujours compatible avec les mensonges (ceci n'est pas un troll, c'est une observation lors d'un projet précédent... mais ce n'est pas un sujet de débat ici) des commerciaux qui se sont engagés à fournir un systeme opérationnel avec des délais très courts pour une équipe très réduite.

              • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

                Posté par  . Évalué à 2.

                Il en l'impose pas, mais la permet c'est deja ca.

                On peut se retrouver a faire une structure quasiment plate (ouais je l'ai fait aussi) pour gagner en simplicité/temps/flemme.

                Mais on aura toujours la possibilite de modifier apres coup.

                Avec tout les languages/environnements/systems on peut faire le porc et on peut meme faire des trucs propres avec des environnements qui n'y poussent pas.

                Mais il y'a quand meme une pente naturelle...

                Bref mon propos n'etais pas de dire que PgSQL pousse a l'excellence, ce serai trop beau, mais plutot qu'il convient mieux au personnes ayant l'habitude des methodes formelles tradis avec les SGBDR.

                I.E : on se sent plus chez soit sur Pg en venant de Oracle que DB2 que chez MySQL.

                C'est moins une question qualitative que d'habitures de dev (de toute façon moi j'aime mieux Berkerley DB plutot que MySQL :-p ).

      • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

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

        Les gens qui disent que mySql "leur suffit" n'ont jamais eu à se plaindre des bugs et des manques techniques de mySql,

        C'est bizarre, j'entends d'ici les DBA Oracle dirent la même chose sur PostgreSQL...


        J'ai utilisé Oracle pendant 10 ans. Pour 99% des applications tournant sur Oracle, je pense que Postgres lui est préférable. Oracle est utile sur des applications géantes comme la facturation détaillée du téléphone où l'on peut trouver des tables réparties sur plusieurs machines. Mais si on n'a pas besoin de ça, il n'y a pas besoin d'Oracle.

        Avec Oracle, c'est à l'utilisateur de définir la taille des tablespaces, des tables et des extends puis de surveiller leur comportement et de recréer la BD avec de nouvelles valeurs quand elle se remplit. Cela provient des anciennes machines comme MVS où la taille d'un fichier devait être définie à la création. Avec les FS modernes ces opérations sont quelque peu archaïques car elles créent un niveau de gestion inutile... Mais elles justifient la présence d'un administrateur Oracle.
        Avec postgresql, le simple df que fait de temps à autre tout bon sysadmin suffit. Il n'y a pas que le prix des licences à économiser !

        • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

          Posté par  . Évalué à 3.

          euuuh, j'ai comme un doute sur le fait que faire un df fasse de toi un dba d'autre chose qu'une petite base de données. Il y a la partie tuning et maintenance qui occupe pas mal de temps.
          Ce n'est pas vraiment modifier les allocs primaires et secondaires d'un tablespace qui sont les plus couteuse en temps.

          ps: on dit z/OS maintenant, MVS, c'etait il y a 10 ans

        • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

          Posté par  . Évalué à 3.

          En même temps rien ne t'empêche de mettre le maxextents à "unlimited" (ce qui est assez crade), ou, à partir de la 8i ou de la 9, de laisser Oracle gérer ces paramètres tout seul ("autoallocate"). Donc niveau facilité d'administration, ça s'est quand même arrangé depuis la 7.

          On est d'accord sur le fait que dans 99% des cas, c'est toujours une ou plusieurs licences de crachée pour rien, toutes les fonctionnalités utilisées étant présentes dans PostgreSQL.

        • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

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

          Lors du dernier forum PHP un des conférenciers, ancien d'Oracle (http://www.afup.org/forumphp2004/conferenciers.php#dd(...)) a fait une conférence sur PHP et Oracle.

          A la fin de sa conférence il a indiqué que selon lui pour la majorité des applications MySQL suffisait largement.
          Il est allé jusqu'a conseiller de commencer par se baser sur MySQL et si jamais a un moment on sentait les limites de MySQL (apres avoir optimisé le serveur bien sur, donc potentiellement assez loin) il conseillait de tourner la tête vers du Oracle.

          Le fait que ce soit un ancien d'Oracle qui dise ca m'a fait tilter sur le fait que c'est vraiment une bonne base de données qui n'a pas a rougir de son statut OpenSource.

          Pour PostGreSQL il n'y a rien à dire c'est aussi une tres bonne base de données mais pour obtenir de bonnes performances il faut pas mal travailler à l'optimisatione t à la configuration du serveur.

          La page du conférencier en question :
          http://didier.deleglise.free.fr/(...)

    • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

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

      > MySql n'est libre, cela appartient à MySQL AB Company, qui a un
      > marketing et une propagande supérieurs.

      Tu veux probablement dire "MySQL n'est pas libre". Mais dans ce cas tu as tort. MySQL est libre. Il est (aussi) en GPL, et ça valide toutes les définitions de "logiciel libre" que j'ai eu l'occasion de voir ici.

      Notes que Mozilla appartient à la Fondation Mozilla, que Gentoo appartient à Gentoo inc (ou appartenait, je n'ai pas suivi l'affaire) , qt appartient à trolltech, evolution appartenait je crois à ximian, emacs a appartenu à RMS .... euh ... ça veut dire que ce n'est pas libre ?

      Seuls les logiciels dont le propriétaire du copyright est flou (ou avec énormément de contributeurs externes) peuvent être libre ? c'est quoi cette nouvelle définition du libre ?

      > MySql se contente de singer quelques fonctionnalités SQL

      Ca ne supporte pas tout, très loin de là (à ma connaissance aucun SGBD ne peut se targuer d'être entièrement compatible SQL99), mais de là à dire qu'il singe SQL, il y a un gros pas, un vrai fossé même.

      > Pour terminer, les benchmarks récents montre que PostgreSQL
      > monte mieux en charge que mySql, et que les perfs globales sont
      > finalement meilleures avec PostgreSQL.

      URL ? source ? je n'ai vu que deux ou trois bench sérieux et objectifs la dessus, et tous sont assez vieux. De plus ils dépendent très fortement de la configuration (concurrence des requêtes, ratio lecture/écriture, type de données, types de requêtes, etc.). Au final il y a de très grosses DB qui tournent sous MySql sans problèmes et pour qui c'est tout à fait pertinent, d'autres pour qui pgsql est plus intéressant.
      Sans vouloir encenser Mysql, sans certainement contredire ceux qui veulent diffuser plus largement pgsql, je crois que tu fais fausse route à être aussi catégorique.

      • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

        Posté par  . Évalué à 3.

        > > MySql se contente de singer quelques fonctionnalités SQL
        >
        > Ca ne supporte pas tout, très loin de là (à ma connaissance aucun SGBD ne peut se targuer d'être entièrement compatible SQL99), mais de là à dire qu'il singe SQL, il y a un gros pas, un vrai fossé même.


        MySQL est "spécial" :
        http://sql-info.de/mysql/gotchas.html(...)
        Et pour postgresql (alors qu'il a plus de fonctionnalité) :
        http://sql-info.de/postgresql/postgres-gotchas.html(...)

        • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

          Posté par  . Évalué à 3.

          Liens très intéressant (démonstrations convaincante vu mon niveau très moyen en SQL)mais je me demandais quand même si le site était pas pro-postgresql en regardant la page principale (que des news sur postgresql actuellement) . C'est dommage que l'auteur est pas permis l'ajout de commentaires par les visiteurs, cela aurait donné une vision plus juste de l'article. Donc j'aimerais bien avoir l'avis d'utilisateurs plus expérimentés, histoire de voir.

    • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

      Posté par  . Évalué à 4.

      MySql [...] a des GUI clickodromes (sous win32 la plupart)

      Sur le site mysql.com, tu trouveras les nouveaux outils graphiques nommés Administrator et Query Browser disponibles pour Linux en tgz ou rpm avec les sources, le tout disponible sous GPL ou licence commerciale.
      Et pour les utiliser tous les deux, je peux te garantir que je vais bien plus vite qu'avec une session en mode console, donc merci mysql de fournir des outils de ce genre en GPL.

      Quelques captures d'écran pour les sceptiques :
      http://www.mysql.com/products/administrator/(...)
      http://www.mysql.com/products/query-browser/(...)

    • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

      Posté par  . Évalué à 0.

      Quasiment tout d'accord, sauf que moi je prefere Ms Access a MySQL (license mise a part, et encore, parceque les licence MySQL c'etait assez joyeux jusqu'a il y'a peut).

      --
      /me va se cacher tres loin avant que le troll lui retombe sur la tronche

    • [^] # Re: Bonne raison de changer de mySql à PostgreSQL

      Posté par  . Évalué à 1.

      Est-ce qu'il y a un document expliquant les incompatibilités entre les deux pour passer une base mysql a postgresql en douceur ?

  • # PostgreSQLFr.org : quelques soucis aujourd'hui...

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

    Bonjour à tous,

    Merci de partager nopre enthousiasme avec cette sortie de la v.8 ! Quelle version majeure!

    Par contre, veuillez nous excuser pour le fonctionnement largement dégradé du site PostgreSQLFr.org, cela s'appelle le "syndrome LinuxFr"... plusieurs centaines de connections d'un coup depuis la publication de cette news!

    Pour être bref: le site est hébergé gracieusement par mon ami Nicolas sur son Open Brick, au sein d'un hébergeur pro-libre, quelque part sur un Oasis Perdu.

    L'Open Brick a un tout petit processeur et un disque dur de portable... sans parler des 256 Mo de ram |-(

    Tous les gens qui travaillent sur PostgreSQLFr.org sont des bénévoles, la pluspart d'entre nous vont même jusqu'à investir de leurs deniers personnels pour que tout cela tourne.

    Nous montons actuellement une association loi 1901, baptisée «PostgreSQLFr.org», vous pourrez nous rencontrer à Solutions Linux 2005... Nous espérons beaucoup de cette association...

    En attendant, si jamais vous aviez un serveur qui traîne, n'hésitez surtout pas à nous le donner :-P...

    Merci à tous pour votre soutien.

    --
    Jean-Paul Argudo
    www.PostgreSQLFr.org

  • # Take back the RDBMS

    Posté par  . Évalué à 5.

    C'est LA version qui va enfin permettre de se débarrasser de MS SQL Server dans de nombreuses boîtes, mais aussi de MySQL, trop souvent déployée par effet de mode sans tenir compte de son manque de certaines fonctionnalités cruciales pour les serveurs de données d'entreprises (je ne parle pas des serveurs web, où MySQL a fait ses preuves depuis pas mal de temps, même si OS News par exemple a basculé vers Postgres qui tient mieux les pics de charge). Et comme un certain nombre de boîte utilise SQL Server quand elles devraient utiliser Oracle ou Sybase ou DB2, PostgreSQL a toutes les chances de faire un putsch sur les bases de données d'entreprise. D'autant que celles-ci se rendront vite compte qu'en plus de remplacer leurs vieilles bases, Postgres peut tenir tête aux meilleurs RDBMS actuels et être au coeur du système de gestion de l'entreprise.

    • [^] # Re: Take back the RDBMS

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

      Quand tu parles des fonctionnalités cruciales qu'il manque a MySQL qu'entends tu par la ?
      As tu regardé la version 4.1 et la 5 (qui tourne plutôt bien malgré qu'elle ne soit pas encore officiellement stable) ?

      Cyril

      • [^] # Re: Take back the RDBMS

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

        Juste une remarque pour indiquer que je suis personellement tres heureux de la sortie de postgreSQL v8 et que je lui souhaite plein de succès.
        Ma question précédente n'est pas un troll mais une interogation !

      • [^] # Re: Take back the RDBMS

        Posté par  . Évalué à 4.

        Il est vrai que MySQL rattrappe son manque de fonctionnalités à grand pas ces derniers temps. Je suis moi aussi bien curieux de savoir quelles fonctionnalités manquent encore à l'appel dans les dernières versions...

        Enfin, il serait prudent d'attendre une stabilisation de ces fonctionnalités pour établir des comparaisons. On parle bien de bases de données d'entreprise en production là ?

        • [^] # Re: Take back the RDBMS

          Posté par  . Évalué à 3.

          Un des gros manques qui a été comblé avec la 4.1 de production est à mon sens les sous-requêtes...

          Les fonctionnalités qui feront leur apparition avec la version 5.0 :

          - les vues
          - les triggers
          - les procédures stockées

          • [^] # Re: Take back the RDBMS

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

            Pour moi LA fonctionnalité de 4.1 que j'attendais c'est le support unicode (et oui, pas d'UTF8 avant, à moins de gérer ça comme un gros champ binaire sans contrainte de taille)

      • [^] # Re: Take back the RDBMS

        Posté par  . Évalué à 4.

        Salut,

        Il est prévu d'implémenter les vues dans la version 5.0 ou 5.1 du serveur MySQL.


        Les procédures stockées sont implémentées en version 5.0.
        j'ai pas vu de GRANT sur procedure stocké là tjs pas en 5.0 ?

        les tables InnoDB supportent les vérifications d'intégrité référentielles. See section 16 Tables InnoDB. Pour les autres types de tables, le serveur mySQL accepte la syntaxe FOREIGN KEY dans la commande CREATE TABLE, mais ne la prend pas en compte.


        je suis loin d'y connaitre quelque chose en bdd mais bon visiblement avant la version 5.1 je la prend même pas en considération...

        • [^] # Re: Take back the RDBMS

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

          > Pour les autres types de tables ...

          Ben oui, innodb est le moteur de table que tu qualifiera peut être de "professionnel" ou de "complet". A toi de l'utiliser. Le fait qu'il existe d'autres moteurs, en plus, qui gèrent d'autres types de problématiques et de besoins, j'ai du mal à voir ça comme un défaut ou désavantage (ce que ta citation laisse entendre).


          Après certes mysql a de gros trains de retard au niveau de certaines fonctionnalités, il est par contre largement dans le groupe de tête poru certaines autres problématiques.
          Tout le monde n'a pas besoin d'un SGBDR qui "fait tout", au contraire. (ce qui ne veut pas dire que certains manquent ne sont pas gênant, je te l'accorde)

      • [^] # Re: Take back the RDBMS

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

        une bonne adresse :-) :
        http://troels.arvin.dk/db/rdbms/

      • [^] # Re: Take back the RDBMS

        Posté par  . Évalué à 1.

        Les requètes imbriquées ?

    • [^] # Re: Take back the RDBMS

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

      Aurait-on un benchmark entre MS SQL Server 2000 et PostgreSQL, parce que j'ai un MS SQL server au boulot et il commence sincèrement à me brouter la tête.

      Merci

      • [^] # Re: Take back the RDBMS

        Posté par  . Évalué à 1.

        Sachant que les benchmarks ne sont pas toujours fiables, peut-être que dans ton cas, tu devrais faire les tests toi-même: avantage, tu connais l'utilisation de ta db donc, tu sauras quoi mesurer :-)

  • # Dossier de Presse

    Posté par  . Évalué à 4.

    Bonjour,

    vous trouverez le dossier de presse sur la page francophone http://www.postgresqlfr.org/?q=node/view/130.(...) La communauté française, comme en a parlé Jean-Paul plus haut, est heureuse de présenter cette nouvelle version et vous attend sur la liste pgsql-fr-generale@postgresql.org, sur le site web http://www.postgresqlfr.org(...) et sur IRC #postgresqlfr sur freenode.

    --
    Jean-Christophe Arnu
    PostgresSQLFr

  • # Mise à jour

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

    L'un des point noir de PostgreSQL, et peut être d'autre SGBDR, est le passage d'une version à une autre.

    Du fait de changements dans la structure interne des BDD, la mise à jour de PostgreSQL nécessite de faire à la main un dumpall de toutes les BDD pour ensuite les restaurer. Il ne semble pas que les dev de PostgreSQL aient prévu d'outil de mise à jour migrant les BDD.

    Comment se déroule un changement de version pour les autres SGBDR ?

    • [^] # Re: Mise à jour

      Posté par  . Évalué à 2.

      c'est un détail. en effet, il faut aussi faire un backup de sa base de données, et du système entier d'ailleurs.

      • [^] # Re: Mise à jour

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

        Ce qui permettra aussi une réorganisation totale de la base ce qui n'est jamais mauvais.

      • [^] # Re: Mise à jour

        Posté par  . Évalué à 4.

        "c'est un détail".....

        pour un RDBMS censé être utilisé par des systèmes en production, et pour des bases "sérieuses " (> 500 Go), ce n'est pas vraiment un détail....

        va dire a un DSI que son application métier (caisse enregistreuses de Carrefour, par exemple), va devoir être arrêtée pendant 1 ou 2 jours, histoire de migrer la version du SGBD....


        c'est pas pour lancer un troll, mais non, pour le moment, les bases de données open source ne peuvent pas remplacer les SGBDs propriétaires (Oracle ou DB2), de par le manque de certaines fonctionnalités qui peuvent sembler triviale quand on a de petits volumes, ou de faibles contraintes de disponibilités, mais quand sont indispensable dans des environnements de production....

        ceci, PGSQL est un très bon outil, très intéressant de par ses fonctionnalités qui suivent de plus en plus celles d'Oracle...

        A quand le cluster actif ???

        • [^] # Re: Mise à jour

          Posté par  . Évalué à 0.

          > va dire a un DSI que son application métier (caisse enregistreuses de Carrefour, par exemple), va devoir être arrêtée pendant 1 ou 2 jours, histoire de migrer la version du SGBD....

          Fait ça en paralèlle. Deux machines ou deux serveurs postgresql. La vieille version dans un coin et la nouvelle dans l'autre :
          pg_dump ... | pg_restore ...

          Inutile d'arrêter le système il doit être en lecture seul. Puis tu bascules sur la nouvelle version.
          Tu peux aussi utiliser la réplication (la réplication n'impose pas d'avoir des versions identique ni d'être en lecture seul).

          Puis, faut pas rèver, les autres SBGR changent aussi de format de donnée de "temps à autre". Comment tu fais avec mysql pour passer à la version 4.0 ? Comment tu fais pour utiliser le format ISAM ? => dump & restore.

          > c'est pas pour lancer un troll, mais non, pour le moment, les bases de données open source ne peuvent pas remplacer les SGBDs propriétaires (Oracle ou DB2), de par le manque de certaines fonctionnalités qui peuvent sembler triviale

          Joli troll.


          Pour "info", le dump/restore de postgresql est pour le changement majeur de version uniquement. Dans les cas de changement de version majeur tu _dois_ toujours faire un test.
          Puis tu n'es pas obligé de monté en version.

        • [^] # Re: Mise à jour

          Posté par  . Évalué à 4.

          Juste pour préciser que l'upgrade de base de données Oracle n'as rien de triviale non plus. Surtout compte-tenu du fait qu'oracle optimise les requètes et que ces optimisations changent d'une version majeure à l'autre) . Donc les temps de traitements aussi (j'ai déjà vu perso des traitements durer dix fois plus longtemps à cause de chose comme çà et quand le traitement durait 5 minutes à la base ça fait mal). Cela nécessite donc tout une série de tests qui peuvent durer très longtemps surtout avec de grosses bases.
          Donc oui pour moi la migration des données d'une version de SGBDR à la version supérieure n'est qu'un détail. L'important c'est d'être sûr que tout fonctionnera au moins aussi bien qu'avant.

          Sinon je suis pas DBA mais bon j'ai déjà travaillé avec quelques un en environnement bancaire et j'ai bien vu que les migrations de DB sont des projets planifiés plusieurs mois à l'avance et mobilisant aussi beaucoup de personnes. Pour conclure je dirais pas qu'il ne manque rien à postgresql (surtout vu l'état de mes connaissances en DB) mais juste que ton exemple n'était pas bon.

    • [^] # Re: Mise à jour

      Posté par  . Évalué à 1.

      > L'un des point noir de PostgreSQL
      > la mise à jour de PostgreSQL nécessite de faire à la main un dumpall

      Ça dépend, c'est uniquement pour les changements majeurs de version. Mais le point noir ce n'est pas PostgreSQL mais les admin qui ne font pas de sauvegarde avec un dump!
      A ma connaissance il n'y a que berkeley db qui supporte les backups en copiant les fichiers. Pour les autres SGBD il faut faire un dump (sinon il y a risque de corruption, etc).

      • [^] # Re: Mise à jour

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

        Tu peux toujours copier les fichiers s'ils n'y a pas d'application qui tourne. Par exemple, pour un backup Oracle, tu stoppes les process Oracle et ça roule. A noter que mysql, sait faire une copie à chaud, par copie physique, si tu n'as que des tables ISAM avec mysqlhotcopy

      • [^] # Re: Mise à jour

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

        Tu peux toujours copier les fichiers s'ils n'y a pas d'application qui tourne. Par exemple, pour un backup Oracle, tu stoppes les process Oracle et ça roule. A noter que mysql, sait faire une copie à chaud, par copie physique, si tu n'as que des tables ISAM avec mysqlhotcopy

      • [^] # Re: Mise à jour

        Posté par  . Évalué à 1.


        A ma connaissance il n'y a que berkeley db qui supporte les backups en copiant les fichiers. Pour les autres SGBD il faut faire un dump (sinon il y a risque de corruption, etc).

        On y arrive aussi avec Oracle en utilisant 2 ou 3 commandes obscures au moment de remonter la base...

        • [^] # Re: Mise à jour

          Posté par  . Évalué à 3.

          Je l'ai déjà fait aussi sans probleme sous Postgres 7.4.3....

          ...pas à chaud bien sûr! Mais, ca se fait bien, en faisant toutefois une petite manip' pour remonter la base. De mémoire, le répertoire racine correspondant à chaque BDD porte un numéro (au lieu d'un nom) tel que 0, 1, 2... mais encore faut-il que ce répertoire ait été créé par le SGBD, afin que le SGBD ait une référence sur ce répertoire. Il m'a donc suffi de recréer une base vide et d'y copier mes fichiers préalablement sauvegardés pour remonter une base opérationnelle.

    • [^] # Re: Mise à jour

      Posté par  . Évalué à 3.

      Pour un upgrade pour oracle (8.1.7.4) j'ai été obligé d'arrêter toutes le db puis de les redémarrer une par une et manuellement lancer des scripts pour mettre à jour des tables systèmes, cela m'a pris un jour et demi.

      Donc pour postgres cela n'est pas si dérangeant, quand on passe d'une version Oracle à une autre on doit faire aussi un import/export des instances.

      • [^] # Re: Mise à jour

        Posté par  . Évalué à 2.

        négatif...

        dans certains cas, on peut faire un "upgrade", en fonction des versions de départ / arrivée.

        Cela consiste à arrêter proprement l'instance d'origine (disons, 8.1.7), installer les binaires nouveaux (10g par exemple), remonter l'instance, et exécuter un script de mise à jour pour le dictionnaire interne de données.

        -> pas de déplacement physique des données !!!! ce qui a son importance avec des bases volumineuses. Le temps d'upgrade est maîtrisé (grosso modo, 1 à 2h), quel que soit le volume

        le dump (export / import), c'est bien pour les petites bases, mais pas jouables sur de vraies bases (d'autant plus qu'il faut être capable de recréer la structure physique de la base d'origine)... pour info, une base de 500 Go, c'est un arrêt de service de 2 jours ou plus....

        qui dit mieux ????

    • [^] # Re: Mise à jour

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

      La migration entre version est plutot très simple pour PostgreSQL vis à vis des autres RDBMS !
      Pour s'en convaincre, essayez avec Oracle, vous serez pas déçus !!! ;-)

      • [^] # Re: Mise à jour

        Posté par  . Évalué à 1.

        Avec Oracle, dans le meilleur cas, je maîtrise totalement la durée de ma migration: 1 à 2 heures maxi, quel que soit le volume de la base à migrer.

        et c'est pas si compliqué que ça....

  • # Système SIG

    Posté par  . Évalué à 4.

    La brique qu'il manquait pour compléter le support windows d'un système SIG sous GPL

    http://qgis.sourceforge.net/(...)
    http://postgis.refractions.net/(...)

  • # Critiques et interrogations.

    Posté par  . Évalué à 1.

    Ce qui me gêne un tout petit peu, et qui peut être n'est plus
    d'actualité, c'est deux choses principalement:

    1) pour sécuriser un postgresql, écrire un patch pour qu'il se chroot
    n'est pas trivial, en effet, lors de la création de tables il utilise
    les commandes cp et rm, donc coder le patch n'a plus vraiment d'interet
    puisque l'idee c'était justement de ne plus devoir recreer une arborescence
    propre... J'ai régler le problème en utiliser des binaire cp et rm compilé
    statiquement avec la dietlibc. La conclusion c'est que c'était un peu
    plus long que prévu.

    2) Comment on fait pour ajouter des utilisateurs dynamiquement ? Chose
    triviale avec Mysql, il m'est impensable de laisser le fichier d'authentification
    accessible au processus postmaster ou à un de ses fils. Du coup je ne
    peux pas utiliser cette base pour faire de l'hébergement de manière simple.

    Ce sont vraiment ces deux points qui me chagrinent. Car pour le reste,
    je lis beaucoup mieux le C que le C++ et je trouve les capacités d'extensions
    de cette base beaucoup plus intéressantes.

    • [^] # Re: Critiques et interrogations.

      Posté par  . Évalué à 1.

      > 1) pour sécuriser un postgresql, écrire un patch pour qu'il se chroot
      n'est pas trivial, en effet, lors de la création de tables il utilise
      les commandes cp et rm, donc coder le patch n'a plus vraiment d'interet
      puisque l'idee c'était justement de ne plus devoir recreer une arborescence
      propre...


      J'y comprend rien. Pourquoi tu veux chrooter alors que postgresql tourne sous le compte postgresql ?

      > 2) Comment on fait pour ajouter des utilisateurs dynamiquement ?

      Commande : CREATE USER
      Description : définit un nouveau compte utilisateur de base de données
      Syntaxe :
      CREATE USER nom [ [ WITH ] option [ ... ] ]

      avec comme options :

      SYSID uid
      | [ ENCRYPTED | UNENCRYPTED ] PASSWORD 'mot_de_passe'
      | CREATEDB | NOCREATEDB
      | CREATEUSER | NOCREATEUSER
      | IN GROUP groupe_utilisateur [, ...]
      | VALID UNTIL 'temps_absolu'


      > il m'est impensable de laisser le fichier d'authentification accessible au processus postmaster ou à un de ses fils.

      Les mots de passe sont cryptés (comme /etc/passwd, .htaccess, etc). Ils sont dans la base de donnée (comme mysql).
      Puis comment tu veux faire une authentification sans avoir accès aux mots de passe ?
      Je ne vois pas de différences avec MySQL.

      Tu peux aussi utiliser LDAP ou kerberos.

      • [^] # Re: Critiques et interrogations.

        Posté par  . Évalué à 2.

        > J'y comprend rien. Pourquoi tu veux chrooter alors que postgresql tourne sous
        > le compte postgresql ?

        Ce n'est absolument pas suffisant, que faire si le programme exécute un binaire
        suid'é ? Que faire s'il écrit dans un répertoire du système ?
        LOAD de mysql afin de lire n'importe quel fichier sur la machine hote, depuis
        PHP ne te rappelle rien ?
        De toute facon tout daemon doit se chrooter... Et changer d'identité, et en
        aucun ne doit pouvoir lire autrechose que ses données.



        > commande : CREATE USER

        Merci.


        > Les mots de passe sont cryptés (comme /etc/passwd, .htaccess, etc). Ils sont
        > dans la base de donnée (comme mysql). Puis comment tu veux faire une
        > authentification sans avoir accès aux mots de passe ?

        C'est d'écriture dont je parlais, mais c'était dans un environnement particulier
        ou le système disposait de 'roles' particuliers. Dans certains environnements ajouter
        ou modifier un utilisateur ne se fait pas à n'importe quel heure et nécessite
        beaucoup d'échanges de mails...

        Ensuite,
        CREATE USER peut visiblement modifier ce fichier.
        Tu as parfaitement raison. Encore merci.

        Je vais pouvoir me repencher dessus du coup !

        • [^] # Re: Critiques et interrogations.

          Posté par  . Évalué à 2.

          > Ce n'est absolument pas suffisant, que faire si le programme exécute un binaire suid'é ?

          Virer le programme suid.

          > Que faire s'il écrit dans un répertoire du système ?

          avoir les répertoires système en rw uniquement pour root (bref, la configuration par défaut).

          > LOAD de mysql afin de lire n'importe quel fichier sur la machine hote, depuis
          PHP ne te rappelle rien ?

          Et alors ? Si ton système est mal configuré, que veux-tu y faire ?
          Pour un serveur, il faut suexec (d'apache) et un compte par site (donc passer par cgi). Là tu n'as pas de problèmes (ou très peut). Pour load de mysql, il n'a lire les données "privées". S'il le fait alors tu as un problème de configuration.


          Sinon, tu chrootes tes utilisateurs aussi ?

          • [^] # Re: Critiques et interrogations.

            Posté par  . Évalué à 1.

            Pourquoi mes utilisateurs auraient accès à cette machine?
            Malheureusement non.

            Je suis obligé de patché le programme car il existe des environnements
            ou tu ne peux pas être root, tu peux juste demander au root
            de lancer tes trucs.

            Mon problème se pose surtout dans le cas ou la machine héberge
            des logiciels propriétaires qui ne permettent pas de toucher à
            quoi que ce soit sous peine de plus être supporté.

            Je n'ai pas la chance d'utiliser postgresql sur une machine dédiée.
            Et je ne suis pas root sur la machine.

            L'admin local ne sait pas comment on fait une cage chroot. Donc
            je lui mache le travail...

  • # python

    Posté par  . Évalué à 1.

    Qu'est-ce que vous utilisez pour l'attaquer en python ?
    pypgsql psycopg ou pygresql ? (si quelqu'un pouvait décrire les avantages et inconvénients de chacun...)

    • [^] # Re: python

      Posté par  . Évalué à 2.

      Vaguement de ce que j'avais cru comprendre (donc à recouper) :

      - pygresql : semble le moins bien du lot, le plus vieux mais toujours avec quelques problèmes,
      - pypgsql : fonctionne assez bien,
      - psycopg : le plus performant notamment utilisé par zope.

      Il y a aussi popy qui à l'air intéressant. De mon coté j'utilise psycopg mais je n'ai pas testé serieusement les autres.

    • [^] # Re: python

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

      http://ggimenez.free.fr/article.php?id_article=6(...)

      mes 2 cents

  • # Recherche outil d'administration désespérement...

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

    Pour faire une percée sur les pages web, il faudrait un support des FAI qui ne voient qu'en MySQL. Mais pour cela, il faudrait à pg un outil d'administration aussi performant que phpmyadmin... phppgadmin en est loin, très loin, j'utilise les 2 car travaillant avec les 2 types de bases, et les limitations de phppgadmin sont criantes, phpmyadmin offrant des dizaines de fonctionnalités supplémentaires. C'est dommage, parce que pg n'a pas le succès qu'il mérite, et une conccurence plus acharnée ne serait que bénéfique pour les 2 BD.

Suivre le flux des commentaires

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