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
- Nouveautés (3 clics)
- Site officiel (4 clics)
- Site français (2 clics)
# Spip
Posté par Greg (site web personnel) . Évalué à 2.
ya bien une version non-officiel de Spip (pgspip), faut esperer qu'il suive ....
[^] # Re: Spip
Posté par kasi . Évalué à 4.
# Autre news
Posté par CoCoZ (site web personnel) . Évalué à 5.
http://www.labo-linux.org/index.php?page=news&id=596(...)
# Pythie
Posté par Jiel (site web personnel) . Évalué à 6.
[^] # Re: Pythie
Posté par blobmaster . Évalué à 1.
# Bonne raison de changer de mySql à PostgreSQL
Posté par VACHOR (site web personnel) . Évalué à 5.
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 fabien . Évalué à 5.
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 jcs (site web personnel) . Évalué à 5.
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 cumulus . Évalué à 1.
Une raison de plus pour essayer ! Merci pour l'info.
[^] # Re: Bonne raison de changer de mySql à PostgreSQL
Posté par Gniarf . Évalué à 2.
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 Euclide (site web personnel) . Évalué à 5.
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 dcp . Évalué à 10.
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 Gluck_ (site web personnel) . Évalué à 5.
[^] # Re: Bonne raison de changer de mySql à PostgreSQL
Posté par jerome (site web personnel) . Évalué à 3.
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 Gniarf . Évalué à 9.
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 Jerome Alet (site web personnel) . Évalué à 2.
> 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 Gniarf . Évalué à 1.
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 Jerome Alet (site web personnel) . Évalué à -3.
[^] # Re: Bonne raison de changer de mySql à PostgreSQL
Posté par Olivier Jeannet . Évalué à 3.
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 Gniarf . Évalué à 7.
[^] # Re: Bonne raison de changer de mySql à PostgreSQL
Posté par WH (site web personnel) . Évalué à 3.
[^] # Re: Bonne raison de changer de mySql à PostgreSQL
Posté par dinomasque . Évalué à 5.
Et le navigateur de référence (IE) ne gère PNG que depuis quelques années (avant il fallait un plugin) et encore, abominablement mal.
Si 95% des créateurs sont incapables de faire ce que 95% des utilisateurs ne pourront pas voir, on comprend pour quoi le GIF qui marche chez 100% des créateurs et 100% des utilisateurs (ayant un écran graphique) est encore utilisé. C'est pas plus compliqué.
Le jour ou Adobe et MIcrosoft auront fini de lire la doc PNG les choses changeront certainnement (ou alors les images seront remplacées par du PDF DRMisé qu'Adobe vient d'inventer ...).
BeOS le faisait il y a 20 ans !
[^] # Re: Bonne raison de changer de mySql à PostgreSQL
Posté par GaGadget . Évalué à 2.
http://www.silicon.fr/getarticle.asp?ID=5105(...)
D'ou le PNG et le MNG pour remplacer respectivement le GIF et le GIF animé.
http://www.libpng.org/(...)
Maintenant le brevet est tombé dans le domaine public, ouf, mais autant utiliser des formats ouverts comme PNG !
http://www.openweb.eu.org/articles/png_vs_gif/(...)
[^] # Re: Bonne raison de changer de mySql à PostgreSQL
Posté par Pooly (site web personnel) . Évalué à 1.
(sinon, je trouve la doc de mysql plus claire, hein :-)
[^] # Re: Bonne raison de changer de mySql à PostgreSQL
Posté par morgendorffer . Évalué à 2.
$ rpm -q -l postgresql | grep /usr/bin
...
/usr/bin/psql
> sinon, je trouve la doc de mysql plus claire
???
http://www.postgresql.org/docs/8.0/static/index.html(...)
La doc de PostgreSQL fait parti de ses points forts.
[^] # Re: Bonne raison de changer de mySql à PostgreSQL
Posté par Pooly (site web personnel) . Évalué à 3.
et tu veux montrer quoi en mettant le lien vers la doc ?
Enfin, je donne mon avis personnel, c'est tout ;-)
[^] # Re: Bonne raison de changer de mySql à PostgreSQL
Posté par be_root . Évalué à 3.
La doc de PostgreSQL fait parti de ses points forts.
Je dirais même plus,
http://traduc.postgresqlfr.org/pgsql-fr/index.html(...)
Il se prend pour Napoléon, son état empire.
[^] # Re: Bonne raison de changer de mySql à PostgreSQL
Posté par Dring . Évalué à 6.
- 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 gc (site web personnel) . Évalué à 6.
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 DocteurCosmos . Évalué à 2.
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 Jean-Max Reymond (site web personnel) . Évalué à 6.
Il te faut alors le support des transactions.
[^] # Re: Bonne raison de changer de mySql à PostgreSQL
Posté par morgendorffer . Évalué à 4.
>
> - 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 Gniarf . Évalué à 1.
oops ! c'est ton texte.
[^] # Re: Bonne raison de changer de mySql à PostgreSQL
Posté par dinomasque . Évalué à 3.
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 vaxvms . Évalué à 2.
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 Raphaël SurcouF (site web personnel) . Évalué à 5.
[^] # Re: Bonne raison de changer de mySql à PostgreSQL
Posté par vaxvms . Évalué à 1.
[^] # Re: Bonne raison de changer de mySql à PostgreSQL
Posté par Jacquot Raphael . Évalué à 2.
1. tu mets la carte
2. tu fais ton code
3. tu tapes la somme
4. t'appuies sur [valider]
5. Ecran bleu
et la... http://fr.wikipedia.org/wiki/DTC parce que c'est dimanche soir et que tu es a 200 bornes de chez toi.
[^] # Re: Bonne raison de changer de mySql à PostgreSQL
Posté par nicolassanchez . Évalué à 4.
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 Bertrand D . Évalué à 5.
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 WH (site web personnel) . Évalué à 1.
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 Philippe Makowski (site web personnel) . Évalué à 1.
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 nicolassanchez . Évalué à -4.
Ça c'est de la comparaison... Firebird est un client, pg un serveur...
Firebird t'en as besoin sur ton poste de travail.
Avec Pg, normalement, quand tu accèdes à ta base de données depuis ton poste de travail (sous win, linux...), tu te connectes à un serveur. Rien n'empêche à ce serveur d'être sous Linux.
A mon avis ce qui est important, c'est d'avoir des clients multiplateformes...
[^] # Re: Bonne raison de changer de mySql à PostgreSQL
Posté par Matthieu BENOIST . Évalué à 2.
euh, Firebird, c'est pas firefox, hein...
http://firebird.sourceforge.net/guide/FBFactsheet.html(...)
Tu remarquera qu'il y a trois version, dont une est effectivement "embarquée"
Mitsuaki, qui s'en va faire des tests sur firebird.
[^] # Re: Bonne raison de changer de mySql à PostgreSQL
Posté par nicolassanchez . Évalué à 1.
Ouet, enfin ce que j'ai dit vaut toujours... l'important c'est d'avoir des clients multi-plateformes...
[^] # Re: Bonne raison de changer de mySql à PostgreSQL
Posté par WH (site web personnel) . Évalué à 1.
Par contre, je me suis laissé dire que sous Linux, FB était plus facile à installer que IB...
Version OS : http://info.borland.com/devsupport/interbase/opensource/(...)
[^] # Re: Bonne raison de changer de mySql à PostgreSQL
Posté par Philippe Makowski (site web personnel) . Évalué à 1.
cette version n'est absolument pas maintenue et de plus très buggée !
la suite open source d'Interbase c'est Firebird et rien d'autre, et là le projet est suivi et indépendant de toute boite commerciale, c'est une Fondation qui gère le projet
D'ailleurs Firebird est dans Debian testing et dans le cooker de Mandrake.
[^] # Re: Bonne raison de changer de mySql à PostgreSQL
Posté par Nicolas (site web personnel) . Évalué à 1.
Les plateformes supportées par firebird sont : 32-bit Windows, Linux (i386), Solaris (Sparc et Intel), HP-UX (i386), FreeBSD, MacOS X and Sinix-Z. Des build sont dispo pour WinCE et AIX.
PS :
Sinix est un UNIX de siemens né en 1984. cf http://de.wikipedia.org/wiki/Sinix(...)
[^] # Re: Bonne raison de changer de mySql à PostgreSQL
Posté par Gohar . Évalué à 2.
[^] # Re: Bonne raison de changer de mySql à PostgreSQL
Posté par erik_lallemand . Évalué à 4.
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 morgendorffer . Évalué à 2.
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 erik_lallemand . Évalué à 8.
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 morgendorffer . Évalué à 1.
+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 erik_lallemand . Évalué à 3.
# 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 nicolassanchez . Évalué à 1.
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 Jean-Max Reymond (site web personnel) . Évalué à 7.
[^] # Re: Bonne raison de changer de mySql à PostgreSQL
Posté par Christophe Renard . Évalué à 5.
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 morgendorffer . Évalué à 1.
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 erik_lallemand . Évalué à 4.
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 Christophe Renard . Évalué à 2.
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 Pierre Jarillon (site web personnel) . Évalué à 7.
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 vaxvms . Évalué à 3.
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 Papey . Évalué à 3.
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 Cyril PIERRE de GEYER (site web personnel) . Évalué à 0.
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 morgendorffer . Évalué à 0.
En quoi ?
PostgreSQL est "lent" par rapport à MySQL pour des petites requêtes et sous faible charge. Par contre sous forte charge ou avec des requêtes compliqués PostgreSQL est plus rapide et ce sans rien faire.
[^] # Re: Bonne raison de changer de mySql à PostgreSQL
Posté par Cyril PIERRE de GEYER (site web personnel) . Évalué à 2.
Evidement il est difficile de faire des benchmark. Quelques liens que j'aii retrouvé :
http://www.01net.com/article/253508.html(...)
Personellement les résultats m'etonnent un peu mais comme dit plus haut les benchmark selon la façon dont tu les fais tu leur fait dire ce que tu veux.
Il semble qu'il y ait eu qq discussions à ce sujet sur la liste de postgresqlfr :
http://archives.postgresql.org/pgsql-fr-generale/2004-07/threads.ph(...)
Un point qui m'a intrigué c'est le fait que dans leurs tests ils ne font appel qu'a deux tables.
Un autre benchmark qui contredit le bench ci dessus :
http://www.mysql.com/it-resources/benchmarks/eweek.html(...)
Un autre article (un peu plus ancien) :
http://www.phpbuilder.com/columns/tim20000705.php3(...)
Si qqun a d'autres liens vers des bench qu'il hesite pas a les poster.
[^] # Re: Bonne raison de changer de mySql à PostgreSQL
Posté par Éric (site web personnel) . Évalué à 6.
> 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 morgendorffer . Évalué à 3.
>
> 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 Djouxxx . Évalué à 3.
[^] # Re: Bonne raison de changer de mySql à PostgreSQL
Posté par governator . Évalué à 4.
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 Christophe Renard . Évalué à 0.
--
/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 wilk . Évalué à 1.
# PostgreSQLFr.org : quelques soucis aujourd'hui...
Posté par Jean-Paul ARGUDO (site web personnel) . Évalué à 10.
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 Papey . Évalué à 5.
[^] # Re: Take back the RDBMS
Posté par Cyril PIERRE de GEYER (site web personnel) . Évalué à 4.
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 Cyril PIERRE de GEYER (site web personnel) . Évalué à 1.
Ma question précédente n'est pas un troll mais une interogation !
[^] # Re: Take back the RDBMS
Posté par Cali_Mero . Évalué à 4.
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 DocteurCosmos . Évalué à 3.
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 Éric (site web personnel) . Évalué à 2.
[^] # Re: Take back the RDBMS
Posté par Johann Heymes . Évalué à 4.
j'ai pas vu de GRANT sur procedure stocké là tjs pas en 5.0 ?
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 Éric (site web personnel) . Évalué à 2.
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 Jean-Max Reymond (site web personnel) . Évalué à 3.
http://troels.arvin.dk/db/rdbms/
[^] # Re: Take back the RDBMS
Posté par caboulot . Évalué à 1.
[^] # Re: Take back the RDBMS
Posté par smorico . Évalué à 2.
[^] # Re: Take back the RDBMS
Posté par Nicolas Antoniazzi (site web personnel) . Évalué à 3.
[^] # Re: Take back the RDBMS
Posté par Stephane Wirtel (site web personnel) . Évalué à 1.
Merci
[^] # Re: Take back the RDBMS
Posté par spotty . Évalué à 1.
# Dossier de Presse
Posté par Jean-Christophe Arnu . Évalué à 4.
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
[^] # Re: Dossier de Presse
Posté par CoCoZ (site web personnel) . Évalué à 2.
http://www.postgresqlfr.org/?q=node/view/130(...)
[^] # Re: Dossier de Presse
Posté par patrick_g (site web personnel) . Évalué à 1.
voila c'est corrigé : http://www.postgresqlfr.org/?q=node/view/130(...)
# Mise à jour
Posté par Frédéric Massot (site web personnel) . Évalué à 2.
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 Gniarf . Évalué à 2.
[^] # Re: Mise à jour
Posté par Jean-Max Reymond (site web personnel) . Évalué à 1.
[^] # Re: Mise à jour
Posté par antoinebrunel . Évalué à 4.
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 morgendorffer . Évalué à 0.
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 Djouxxx . Évalué à 4.
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 morgendorffer . Évalué à 1.
> 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 Jean-Max Reymond (site web personnel) . Évalué à 3.
[^] # Re: Mise à jour
Posté par Pooly (site web personnel) . Évalué à 1.
[^] # Re: Mise à jour
Posté par Jean-Max Reymond (site web personnel) . Évalué à 1.
http://dev.mysql.com/doc/mysql/en/mysqlhotcopy.html(...)
[^] # Re: Mise à jour
Posté par Pooly (site web personnel) . Évalué à 2.
http://www.innodb.com/order.php(...)
toutes mes confuses :-)
[^] # Re: Mise à jour
Posté par Jean-Max Reymond (site web personnel) . Évalué à -2.
[^] # Re: Mise à jour
Posté par Crao . Évalué à 1.
On y arrive aussi avec Oracle en utilisant 2 ou 3 commandes obscures au moment de remonter la base...
[^] # Re: Mise à jour
Posté par erik_lallemand . Évalué à 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 spotty . Évalué à 3.
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 antoinebrunel . Évalué à 2.
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 VACHOR (site web personnel) . Évalué à 2.
Pour s'en convaincre, essayez avec Oracle, vous serez pas déçus !!! ;-)
[^] # Re: Mise à jour
Posté par antoinebrunel . Évalué à 1.
et c'est pas si compliqué que ça....
# Système SIG
Posté par Lafrite . Évalué à 4.
http://qgis.sourceforge.net/(...)
http://postgis.refractions.net/(...)
# Critiques et interrogations.
Posté par forc3 . Évalué à 1.
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 morgendorffer . Évalué à 1.
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 forc3 . Évalué à 2.
> 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 morgendorffer . Évalué à 2.
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 forc3 . Évalué à 1.
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 wilk . Évalué à 1.
pypgsql psycopg ou pygresql ? (si quelqu'un pouvait décrire les avantages et inconvénients de chacun...)
[^] # Re: python
Posté par Nim . Évalué à 2.
- 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 Guillaume Gimenez (site web personnel) . Évalué à 1.
mes 2 cents
# Recherche outil d'administration désespérement...
Posté par EppO (site web personnel) . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.