>C'est absolument nécessaire pour offrir une alternative à MS Access.
Pierre, comparer PostgreSQL à Access c'est pas très gentil (je n'ai jamais autant pesé mes mots ;-)...
>J'espère aussi que la mise en oeuvre de postgresql sera facilitée. Il n'est pas évident du tout à un débutant d'aller éditer /var/lib/pgsql/data/postgresql.conf pour y ajouter tcpip_socket = true et d'aller modifier /var/lib/pgsql/data/pg_hba.conf pour y permetter la connexion en mode local (par localhost).
Tous les DBA préfèrent aller modifier un fichier de conf que de se retrouver devant une interface graphique propriétaire toujours limitée et + ou - foireuse (Cf Ms SQL Server). Maintenant si le commentaire s'adresse aux débutants non informaticiens, j'espère réellement qu'aucun d'entre eux n'aura jamais l'idée saugrenue d'installer PostregreSQL. C'est quand même pas un outil pour débutants :)
>Il est indispensable de donner une configuration par défaut qui soit directement utilisable (comme Access).
Argll non alors! Il y a déjà SQLite (et consors) pour ça.
>La réplication de base est une très bonne chose.
Elle y est depuis un bon moment, et de toutes façons rien ne vaut de bonnes procédures stockées pour se faire sa propre réplication aux petits oignons.
>Il serait très intéressant de la faire vers MySQL pour faire de l'infocentre
Pardon, mais je ne vois pas vraiment l'intérêt d'avoir un second moteur pour gagner quelques millisecondes sur les requêtes. Par contre PostgreSQL sera bien plus adapté lorsqu'il faudra mettre en place un Datawharehouse ou bien de l'analyse de données OLAP (Cf. le magnifique projet Mondrian : http://sourceforge.net/projects/mondrian/(...))
>Les cas où Oracle est nécessaire sont vraiment marginaux.
Tout à fait d'accord pour l'édition Standard destinée aux PME-PMI. Par contre quand il s'agit de gérer plusieurs Téra de données ou milliers d'utilisateur, je n'hésiterai qu'entre Oracle et DB2. OSDN a d'ailleurs choisi le dernier si je ne m'abuse.
>C'est dû au fait que Oracle a été conçu pour gérer lui-même les accès disques alors que postgresql laisse le file system s'en débrouiller.
Ayant débuté avec la V3 d'Oracle, je n'ai pas le souvenir d'y avoir vu le support des Raw devices à l'époque (mais je peux me tromper, ça ne date pas d'hier). Je crois que c'est arrivé bien plus tard. Et je continue de penser que c'est une excellente chose: lorsqu'on a bossé plusieurs jours/semaines sur la conception des Lun, on ne va quand même pas tout gacher avec un filestem! Concernant les Tablespace, reste à voir comment ils sont implémentés et ce qu'ils permettent de faire (Cf. partitionnement vertical et horizontal).
J'ajouterai que j'attendais la version 7.5 de PostgreSQL depuis un bout de temps justement pour les Tablespaces. Et puis là je vois arriver une V8 qui d'un point de vue des nouvelles fonctionnalités ne m'impressionne pas plus que celà. Par contre après avoir lu la liste des améliorations je m'aperçois que le paramètre tcpip_socket a été remplacé par un listen_addresses ce qui devrait te faire plaisir. ;-)
Plus sérieusement, la liste des améliorations sur les performances est impressionnante.
Je terminerai ce long message par une 'petite requête' à destination des DBA PostgreSQL: en dehors de pgAdmin, quel outil utilisez-vous pour l'analyse des requêtes (sortie du plan d'exécution)? J'ai lu que les stats et l'optimiseur ont subi quelques changements.
[^] # Re: Quelque liens complémentaires
Posté par Raoul Volfoni (site web personnel) . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 10.
Pierre, comparer PostgreSQL à Access c'est pas très gentil (je n'ai jamais autant pesé mes mots ;-)...
>J'espère aussi que la mise en oeuvre de postgresql sera facilitée. Il n'est pas évident du tout à un débutant d'aller éditer /var/lib/pgsql/data/postgresql.conf pour y ajouter tcpip_socket = true et d'aller modifier /var/lib/pgsql/data/pg_hba.conf pour y permetter la connexion en mode local (par localhost).
Tous les DBA préfèrent aller modifier un fichier de conf que de se retrouver devant une interface graphique propriétaire toujours limitée et + ou - foireuse (Cf Ms SQL Server). Maintenant si le commentaire s'adresse aux débutants non informaticiens, j'espère réellement qu'aucun d'entre eux n'aura jamais l'idée saugrenue d'installer PostregreSQL. C'est quand même pas un outil pour débutants :)
>Il est indispensable de donner une configuration par défaut qui soit directement utilisable (comme Access).
Argll non alors! Il y a déjà SQLite (et consors) pour ça.
>La réplication de base est une très bonne chose.
Elle y est depuis un bon moment, et de toutes façons rien ne vaut de bonnes procédures stockées pour se faire sa propre réplication aux petits oignons.
>Il serait très intéressant de la faire vers MySQL pour faire de l'infocentre
Pardon, mais je ne vois pas vraiment l'intérêt d'avoir un second moteur pour gagner quelques millisecondes sur les requêtes. Par contre PostgreSQL sera bien plus adapté lorsqu'il faudra mettre en place un Datawharehouse ou bien de l'analyse de données OLAP (Cf. le magnifique projet Mondrian : http://sourceforge.net/projects/mondrian/(...))
>Les cas où Oracle est nécessaire sont vraiment marginaux.
Tout à fait d'accord pour l'édition Standard destinée aux PME-PMI. Par contre quand il s'agit de gérer plusieurs Téra de données ou milliers d'utilisateur, je n'hésiterai qu'entre Oracle et DB2. OSDN a d'ailleurs choisi le dernier si je ne m'abuse.
>C'est dû au fait que Oracle a été conçu pour gérer lui-même les accès disques alors que postgresql laisse le file system s'en débrouiller.
Ayant débuté avec la V3 d'Oracle, je n'ai pas le souvenir d'y avoir vu le support des Raw devices à l'époque (mais je peux me tromper, ça ne date pas d'hier). Je crois que c'est arrivé bien plus tard. Et je continue de penser que c'est une excellente chose: lorsqu'on a bossé plusieurs jours/semaines sur la conception des Lun, on ne va quand même pas tout gacher avec un filestem! Concernant les Tablespace, reste à voir comment ils sont implémentés et ce qu'ils permettent de faire (Cf. partitionnement vertical et horizontal).
J'ajouterai que j'attendais la version 7.5 de PostgreSQL depuis un bout de temps justement pour les Tablespaces. Et puis là je vois arriver une V8 qui d'un point de vue des nouvelles fonctionnalités ne m'impressionne pas plus que celà. Par contre après avoir lu la liste des améliorations je m'aperçois que le paramètre tcpip_socket a été remplacé par un listen_addresses ce qui devrait te faire plaisir. ;-)
Plus sérieusement, la liste des améliorations sur les performances est impressionnante.
Je terminerai ce long message par une 'petite requête' à destination des DBA PostgreSQL: en dehors de pgAdmin, quel outil utilisez-vous pour l'analyse des requêtes (sortie du plan d'exécution)? J'ai lu que les stats et l'optimiseur ont subi quelques changements.