Articles précédents : Logiciel
- [35] Sylpheed et Sylpheed-Claws arrivent en version 1.0.0.
- [25] Bugzilla 2.18 est disponible
- [19] Bluefish 1.0 & NVU 0.7
- [16] Sortie de Scribus 1.2.1
- [81] ooo2dbk : Générer du DocBook à partir de documents OpenOffice.org
- [112] Un MMORPG libre
- [148] Sortie de Ruby 1.8.2
- [50] Sortie de Gambas 1.0
- [98] Gimp 2.2.0 (et 2.2.1)
- [13] Compilations de logiciels libres sous Windows : faites-les vous-même!
Liens connexes
- Nouveautés (889 hits)
- Site officiel (878 hits)
- Site français (2894 hits)
Dépêche modérée par
Dépêche éditée par
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).
![[en]](../../../images/en.png)
Nouveautés (889 hits)-
Site officiel (878 hits)
![[fr]](../../../images/fr.png)
Site français (2894 hits)
> Lire la suite (118 commentaires, moyenne: 2,7). [dépêche : 569 caractères]
- 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.
Spip
Vraiment dommage que Spip ne le supporte pas :-(
ya bien une version non-officiel de Spip (pgspip), faut esperer qu'il suive ....
-
[^]Re: Spip
Autre news
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(...)
Bonne raison de changer de mySql à PostgreSQL
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 fabien () le 19/01/2005 à 10:43. (lien). É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 jcs (page perso, ) le 19/01/2005 à 11:15. (lien). É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 cumulus () le 19/01/2005 à 12:44. (lien). É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 Gniarf () le 19/01/2005 à 14:58. (lien). É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)--
"Je n'aime pas votre regard, baissez les yeux!" - Patrick Devedjian, 2008
-
[^]Re: Bonne raison de changer de mySql à PostgreSQL
Posté par Euclide (page perso, ) le 19/01/2005 à 15:13. (lien). É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 dcp (page perso, ) le 19/01/2005 à 11:43. (lien). É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 Gluck_ (page perso, ) le 19/01/2005 à 12:00. (lien). É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 jerome (page perso, ) le 19/01/2005 à 12:40. (lien). É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 Gniarf () le 19/01/2005 à 13:29. (lien). É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à.--
"Je n'aime pas votre regard, baissez les yeux!" - Patrick Devedjian, 2008-
[^]Re: Bonne raison de changer de mySql à PostgreSQL
Posté par Jerome Alet (page perso, ) le 19/01/2005 à 14:16. (lien). É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 Gniarf () le 19/01/2005 à 14:51. (lien). É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.--
"Je n'aime pas votre regard, baissez les yeux!" - Patrick Devedjian, 2008-
[+] [^]Re: Bonne raison de changer de mySql à PostgreSQL
Posté par Jerome Alet (page perso, ) le 19/01/2005 à 15:12. (lien). Évalué à -3.2 fois en deux posts, on dirait que tu as un goût prononcé pour le vomi...
-
-
-
[^]Re: Bonne raison de changer de mySql à PostgreSQL
Posté par Olivier Jeannet () le 19/01/2005 à 14:26. (lien). É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 Gniarf () le 19/01/2005 à 14:43. (lien). Évalué à 7.les gif animés ? :)
--
"Je n'aime pas votre regard, baissez les yeux!" - Patrick Devedjian, 2008-
[^]Re: Bonne raison de changer de mySql à PostgreSQL
-
-
[^]Re: Bonne raison de changer de mySql à PostgreSQL
Posté par Aurélien Girard () le 19/01/2005 à 15:46. (lien). Évalué à 5.Pour les GIF c'est simple, l'outil de référence (totoshop) est réputé pour gérer très mal PNG.
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 10 ans.-
[^]Re: Bonne raison de changer de mySql à PostgreSQL
Posté par GaGadget () le 22/01/2005 à 16:35. (lien). Évalué à 2.Le problème avec le gif était le brevet que détenait Unisys sur l'algo de compression et surtout le fait qu'Unisys voulait faire valoir ses droits : 5000 Dollars pour publier des images gif sur son site !!!
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 (page perso, ) le 19/01/2005 à 19:12. (lien). Évalué à 1.simple à utlisé hummm. En newbie en 1998 j'ai installé Postgresql, j'ai cherché longtemps avant de trouver le nom de la commande qui lance l'interpréteur,on a pas idée de l'appelée pgsql, alors que le soft s'appelle Postgresql !!!
(sinon, je trouve la doc de mysql plus claire, hein :-)-
[^]Re: Bonne raison de changer de mySql à PostgreSQL
Posté par morgendorffer () le 19/01/2005 à 20:36. (lien). Évalué à 2.> j'ai cherché longtemps avant de trouver le nom de la commande qui lance l'interpréteur,on a pas idée de l'appelée pgsql
$ 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 (page perso, ) le 20/01/2005 à 12:58. (lien). Évalué à 3.oui, t'inquiete c'est ce que j'ai fini par faire...
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 (page perso, ) le 22/01/2005 à 10:25. (lien). Évalué à 3.http://www.postgresql.org/docs/8.0/static/index.html(...(...))
La doc de PostgreSQL fait parti de ses points forts.
Je dirais même plus,
http://traduc.postgresqlfr.org/pgsql-fr/index.html(...)--
Les démineurs travaillent d'arrache-pied
-
-
-
-
-
-
[^]Re: Bonne raison de changer de mySql à PostgreSQL
Posté par Dring FirebirdVsMySql () le 19/01/2005 à 12:47. (lien). É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...--
Non, rien.-
[^]Re: Bonne raison de changer de mySql à PostgreSQL
Posté par gc (page perso, ) le 19/01/2005 à 14:19. (lien). É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 DocteurCosmos (page perso, ) le 19/01/2005 à 17:28. (lien). É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 Jean-Max Reymond (Jabber id, page perso, ) le 19/01/2005 à 17:32. (lien). Évalué à 6.>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...
Il te faut alors le support des transactions.--
CKR Solutions Open Source
-
-
-
[^]Re: Bonne raison de changer de mySql à PostgreSQL
Posté par morgendorffer () le 19/01/2005 à 14:40. (lien). É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
-
[^]Re: Bonne raison de changer de mySql à PostgreSQL
Posté par Aurélien Girard () le 19/01/2005 à 15:50. (lien). É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 10 ans.-
[^]Re: Bonne raison de changer de mySql à PostgreSQL
Posté par vaxvms () le 19/01/2005 à 21:06. (lien). É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 Raphaël SurcouF (Jabber id, page perso, ) le 20/01/2005 à 09:14. (lien). Évalué à 5.Attention, des guichets automatiques bancaires commencent à utiliser ...Windows ! Pour en avoir vu un rebooter, ça fait un peu peur...
-
[^]Re: Bonne raison de changer de mySql à PostgreSQL
Posté par vaxvms () le 20/01/2005 à 21:37. (lien). Évalué à 1.Certes mais l'intelligence bancaire est rarement hebergée sur le GAB :-) Elle est plutot sur des gros systèmes type mainframe.
-
[^]Re: Bonne raison de changer de mySql à PostgreSQL
Posté par Jacquot Raphael () le 23/01/2005 à 17:29. (lien). Évalué à 2.experience vecue:
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 () le 20/01/2005 à 07:16. (lien). É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 Bertrand D () le 20/01/2005 à 13:56. (lien). É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 Will Hunting () le 21/01/2005 à 00:07. (lien). É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 Philippe Makowski (page perso, ) le 19/01/2005 à 14:44. (lien). É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 nicolassanchez () le 20/01/2005 à 07:24. (lien). Évalué à -4.Mais c'est vrai qu'au niveau multi plateforme Firebird à de l'avance.
Ç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 () le 20/01/2005 à 08:05. (lien). Évalué à 2.
Firebird est un client, pg un serveur...
Firebird t'en as besoin sur ton poste de travail.
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 () le 20/01/2005 à 08:20. (lien). Évalué à 1.Oups... :-) désolé...
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 Will Hunting () le 21/01/2005 à 00:27. (lien). Évalué à 1.Pour mémoire, Firebird est dérivé d'Interbase, téléchargeable sur le site de Borland : http://www.borland.fr(...)
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 (page perso, ) le 21/01/2005 à 12:31. (lien). Évalué à 1.Ne surtout pas utiliser la version d'Interbase Open-Source !
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 (page perso, ) le 20/01/2005 à 08:09. (lien). Évalué à 1.Oui très juste, mais je pense qu'il parlait de firebird le "gestionnaire de base de données relationelle du nouveau millénaire" (dito http://firebird.sf.net(...) ) . Qui est d'ailleurs à l'origine du changement de nom de firefox auquel je pense tu te référais.
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
-
-
[^]Re: Bonne raison de changer de mySql à PostgreSQL
Posté par erik_lallemand (page perso, ) le 19/01/2005 à 20:00. (lien). É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 morgendorffer () le 19/01/2005 à 20:41. (lien). É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 erik_lallemand (page perso, ) le 19/01/2005 à 22:23. (lien). É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 morgendorffer () le 19/01/2005 à 22:51. (lien). É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 erik_lallemand (page perso, ) le 20/01/2005 à 20:38. (lien). É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 nicolassanchez () le 20/01/2005 à 07:33. (lien). É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 Jean-Max Reymond (Jabber id, page perso, ) le 20/01/2005 à 07:45. (lien). É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.
--
CKR Solutions Open Source
-
-
-
-
[^]Re: Bonne raison de changer de mySql à PostgreSQL
Posté par Christophe Renard (page perso, ) le 20/01/2005 à 07:15. (lien). É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 morgendorffer () le 20/01/2005 à 10:36. (lien). É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 erik_lallemand (page perso, ) le 20/01/2005 à 19:03. (lien). É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 Christophe Renard (page perso, ) le 21/01/2005 à 07:08. (lien). É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 Pierre Jarillon (page perso, ) le 19/01/2005 à 20:57. (lien). É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 vaxvms () le 19/01/2005 à 21:19. (lien). É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 Papey () le 20/01/2005 à 08:00. (lien). É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 Cyril PIERRE de GEYER (page perso, ) le 20/01/2005 à 20:52. (lien). É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 morgendorffer () le 22/01/2005 à 14:24. (lien). Évalué à 0.> 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.
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 (page perso, ) le 23/01/2005 à 17:48. (lien). Évalué à 2.Hum, as tu des liens pour affirmer ce que tu dis morgendorffer ?
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 (Jabber id, page perso, ) le 19/01/2005 à 13:35. (lien). É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 morgendorffer () le 19/01/2005 à 14:54. (lien). É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 Djouxxx () le 19/01/2005 à 20:33. (lien). É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 governator () le 19/01/2005 à 16:47. (lien). É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 Christophe Renard (page perso, ) le 19/01/2005 à 18:03. (lien). É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 wilk (Jabber id, page perso, ) le 20/01/2005 à 11:06. (lien). É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...
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
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 Cyril PIERRE de GEYER (page perso, ) le 19/01/2005 à 11:00. (lien). É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 Cyril PIERRE de GEYER (page perso, ) le 19/01/2005 à 11:02. (lien). É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 Cali_Mero () le 19/01/2005 à 11:25. (lien). É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à ?--
#define MAGIC 0xdefaced /* I should've patented this number -cliph */-
[^]Re: Take back the RDBMS
Posté par DocteurCosmos (page perso, ) le 19/01/2005 à 17:35. (lien). É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 Éric (Jabber id, page perso, ) le 19/01/2005 à 18:38. (lien). É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 Johann Heymes (page perso, ) le 19/01/2005 à 11:41. (lien). É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 Éric (Jabber id, page perso, ) le 19/01/2005 à 13:53. (lien). É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 Jean-Max Reymond (Jabber id, page perso, ) le 19/01/2005 à 12:43. (lien). Évalué à 3.une bonne adresse :-) :
http://troels.arvin.dk/db/rdbms/--
CKR Solutions Open Source
-
[^]Re: Take back the RDBMS
-
[^]Re: Take back the RDBMS
Posté par smorico (page perso, ) le 19/01/2005 à 16:30. (lien). Évalué à 2.Les requettes imbriqués sont supportées depuis la version 4.1
-
[^]Re: Take back the RDBMS
Posté par Nicolas ANTONIAZZI (page perso, ) le 19/01/2005 à 20:58. (lien). Évalué à 3.Le nombre d'imbrication est limité à 3 par contre. C'est suffisant la plupart du temps... mais ce n'est pas non plus ce qu'il y a de plus puissant.
-
-
-
-
[^]Re: Take back the RDBMS
Posté par Stephane Wirtel () le 19/01/2005 à 15:41. (lien). É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
-
Dossier de Presse
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
-
[^]Re: Dossier de Presse
Posté par CoCoZ (page perso, ) le 19/01/2005 à 14:54. (lien). Évalué à 2.Il faut enlever le point à la fin de l'url:
http://www.postgresqlfr.org/?q=node/view/130(...)
-
[^]Re: Dossier de Presse
Posté par patrick_g (page perso, ) le 19/01/2005 à 15:00. (lien). Évalué à 1.Y'a un point à la fin de ton URL qui fait chier non ?
voila c'est corrigé : http://www.postgresqlfr.org/?q=node/view/130(...)
Mise à jour
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 Gniarf () le 19/01/2005 à 14:51. (lien). É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.
--
"Je n'aime pas votre regard, baissez les yeux!" - Patrick Devedjian, 2008-
[^]Re: Mise à jour
Posté par Jean-Max Reymond (Jabber id, page perso, ) le 19/01/2005 à 14:54. (lien). Évalué à 1.Ce qui permettra aussi une réorganisation totale de la base ce qui n'est jamais mauvais.
--
CKR Solutions Open Source
-
[^]Re: Mise à jour
Posté par antoinebrunel () le 19/01/2005 à 19:21. (lien). É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 morgendorffer () le 19/01/2005 à 20:54. (lien). É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 Djouxxx () le 19/01/2005 à 21:01. (lien). É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 morgendorffer () le 19/01/2005 à 14:54. (lien). É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 Jean-Max Reymond (Jabber id, page perso, ) le 19/01/2005 à 15:08. (lien). É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
--
CKR Solutions Open Source-
[^]Re: Mise à jour
Posté par Pooly (page perso, ) le 19/01/2005 à 19:26. (lien). Évalué à 1.mysqlhotcopy gère les tables InnoDB, et le format ISAM a été remplacé par MyISAM dans la 3.23...
-
[^]Re: Mise à jour
Posté par Jean-Max Reymond (Jabber id, page perso, ) le 19/01/2005 à 19:36. (lien). Évalué à 1.allons bon, on m'aurait menti ?
http://dev.mysql.com/doc/mysql/en/mysqlhotcopy.html(...)--
CKR Solutions Open Source-
[^]Re: Mise à jour
Posté par Pooly (page perso, ) le 19/01/2005 à 20:17. (lien). Évalué à 2.Effectivement, j'ai confondu avec :
http://www.innodb.com/order.php(...)
toutes mes confuses :-)
-
-
-
-
[+] [^]Re: Mise à jour
Posté par Jean-Max Reymond (Jabber id, page perso, ) le 19/01/2005 à 15:21. (lien). É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
--
CKR Solutions Open Source
-
[^]Re: Mise à jour
Posté par Côme Desplats () le 19/01/2005 à 15:25. (lien). É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 erik_lallemand (page perso, ) le 19/01/2005 à 19:05. (lien). É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 spotty () le 20/01/2005 à 17:03. (lien). É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 antoinebrunel () le 21/01/2005 à 23:29. (lien). É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 VACHOR (page perso, ) le 21/01/2005 à 09:54. (lien). É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 antoinebrunel () le 21/01/2005 à 23:31. (lien). É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
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.
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 morgendorffer () le 19/01/2005 à 15:46. (lien). É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 forc3 (page perso, ) le 19/01/2005 à 18:18. (lien). É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 morgendorffer () le 19/01/2005 à 18:43. (lien). É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 forc3 (page perso, ) le 20/01/2005 à 08:05. (lien). É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
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 Nim () le 20/01/2005 à 17:05. (lien). É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 Guillaume Gimenez (page perso, ) le 25/01/2005 à 14:17. (lien). Évalué à 1.http://ggimenez.free.fr/article.php?id_article=6(...)
mes 2 cents
Recherche outil d'administration désespérement...
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.
Cette page a été générée par Templeet en 0.3602s (dont 0.0532 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.