Concernant les performances, cette nouvelle version perpétue la montée en puissance de la branche 8 avec un lot de nouvelles fonctionnalités très intéressantes :
- La technologie HOT (Heap Only Tuples) ;
- L'auto-optimisation du processus d'écriture en tâche de fond ;
- La validation asynchrone ;
- L'étalement des points de vérification ;
- Les parcours synchronisés ;
- La réduction des en-têtes varlena ;
- La protection du parcours du cache L2 ;
- L'assignation paresseuse des XID.
- La journalisation applicative au format CSV ;
- SQL/XML ;
- Le support de MS Visual C++ ;
- La gestion des ENUM ;
- La recherche textuelle intégrée ;
- SSPI & GSSAPI ;
- Les tableaux de types composés ;
- pg_standby.
![[en]](../images/en.png)
PostgreSQL (364 hits)![[fr]](../images/fr.png)
Dossier de presse (353 hits)-
Matrice des fonctionnalités (308 hits)
-
Annonce officielle (115 hits)
-
Notes de versions (115 hits)
-
Association PostgreSQLFR (403 hits)
> Lire la dépêche (66 commentaires, moyenne: 3,2).
Vous avez demandé le commentaire #902991.
Run by 
Cette page a été générée par Templeet en 0.0523s (dont 0.0055 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
PostgreSQL oui mais pas tout de suite
En toute honnêteté, j'aime bien PostgreSQL par rapport à MySQL, même si je ne l'ai jamais utilisé vraiment. Mais le fait que ça soit plus proche des standards, juste ça, ça me va. Parce qu'en MySQL, on ne sait jamais si on fait du vrai SQL ou du MySQLisme (pareil que les bashisme vis-à-vis du sh POSIX). Le support des transactions, le support de l'Unicode, le support des clefs étrangères, tout ça, c'est très bien et ça renforce mon opinion par rapport à PostgreSQL.
Seulement voilà, si on veut l'utiliser avec le driver JDBC [1], ben il manque des choses dont j'aimerais bien me servir. Et on voit sur la TODO liste [2] qu'il manque des trucs comme Statement.getGeneratedKeys qui est fort pratique. Ça donne l'impression que ce n'est pas encore tout à fait abouti. C'est dommage parce que je troquerais bien mon MySQL contre un PostgreSQL. J'ai lu les différents fils de discussion concernant cette fonctionnalité et je ne comprend pas bien les problèmes, pour moi il faut que cette fonction retourne la ou les clefs qui ont été générées par un INSERT, pas plus ni moins. Il n'y a peut-être pas le support dans PostgreSQL pour le faire mais ça serait vraiment une superbe fonctionnalité à ajouter.
[1] http://jdbc.postgresql.org/
[2] http://jdbc.postgresql.org/todo.html
[^]Re: PostgreSQL oui mais pas tout de suite
Enfin les drivers JDBC ça ne fait pas partie de pgSQL.
Parce que bon, je ne suis pas sur qu'il y ait une api FORTRAN non plus.
Le truc "pas encore tout à fait abouti" comme tu dis, c'est le driver JDBC en lui-même, pgSQL n'a aucun problème.
Et puis bon, utiliser ce genre de fonctionnalités JDBC, c'est un peu du gâchis avec pgSQL. La solution plus élégante (et surtout plus performante) c'est de faire effectuer le traitement que tu veux par une procédure stockée. Et si tu as besoin de récupérer des IDs, c'est ta procédure stockée qui les retourne.
Le problème de cette nouvelle mode consistant à avoir plein de petits bouts de SQL éparpillés, ventilés, dans du code Java (ou PHP ou n'importe quoi d'autre), c'est d'abord que les performances sont dégueulasses, et ensuite qu'au niveau maintenance ça devient un vrai casse tête.
Si on modifie un nom de table ou un type de colonne, il faut se cogner tous le code JAVA pour essayer de voir où se trouvent les adhérences.
Alors que quand tu fais tes traitements par procédure stockée, tu as tous les traitements sous les yeux mutalisés au niveau du serveur, et si tu rejoues les scripts de création de procédure, tu vois celles qui partent en erreur...
C'est marrant à dire, mais avec cette nouvelle mode de J2E, Struts & co. je vois les gens refaire les mêmes erreurs qu'il y a 15 ans aux débuts du client/serveur avec les premiers NSDK ou PowerBuilder.
[^]Re: PostgreSQL oui mais pas tout de suite
Je suis d'accord avec toi, mais souvent la competence applicative n'est pas chez les DBA, qui en plus sont moins nombreux que les développeurs (et plus chers).
Enfin techniquement, mettre les fonctions applicatives dans les bases de données fini par bouffer de la performance sur la DB et les licenses (ok sur les DB commerciales ...) se paient au nombre de cores utilisés sur le serveur de DB...
J'ajoute que pour le stockage, multiplier les serveurs de DB coute aussi pas mal de fric.
Donc que faire ?
Utiliser la fameuse mode du n-tiers, et mettre un front-end java sur un serveur applicatif pour heberger le code applicatif sous forme de fonctions, publiée en SOAP par exemple.
Ces fonctions SOAP concentrent les appels aux DB (donc y'en a pas partout dans toutes les applis), le SOAP c'est gratuit (java + tomcat / jboss), et cela permet (comme les proc stockées) de rendre les fonctions disponibles pour toutes les applis de l'entreprise.
En bonus, SOAP est un protocole normalisé et disponible sur toutes les plateformes, dans tous les langages (pas la peine de déployer des connecteurs JDBC/ODBC/....)
Mais je suis d'accord avec toi, les proc stockées c'est bien, y'a juste des contrainte en entreprise qui font que d'autres solutions peuvent être préférées.
[^]Re: PostgreSQL oui mais pas tout de suite
je vais répondre aux deux commentaires ci-dessus d'un seul coup.
Tout d'abord, comme dit PLuG, je suis dans un cas totalement similaire, sauf que s/SOAP/XML-RPC/ mais après, c'est la même chose.
Moi je ne suis pas un expert SQL, je veux juste faire des trucs ultra-simple, comme le permet JDBC. Après, je fais ma sauce du côté du Java. Et j'aimerais que mon code marche bien avec toutes les DB imaginables, en particuleir PostgreSQL. Alors ça revient un peu à dire qu'il faut se contenter du plus grand commun dénominateur entre toutes les bases (donc prendre les fonctionnalités de MySQL) mais bon, je ne veux pas utiliser JDBC qui permet d'abstraire la DB et ensuite faire du code SQL spécifique à une DB.
Ensuite, je suis d'accord, c'est pas forcément un problème au niveau PostgreSQL (et même je pense que le problème ne vient pas de là), mais il n'empêche que de nos jours, on utilise rarement une DB directement mais à partir d'API dans ce genre (il y a aussi PDO pour PHP, DBI pour Perl, etc) et qu'il faut également soigner l'implémentation de ces API, ça compte aussi dans l'adoption (c'était l'objet de mon premier post).
[^]Re: PostgreSQL oui mais pas tout de suite
« Si on modifie un nom de table ou un type de colonne, il faut se cogner tous le code JAVA pour essayer de voir où se trouvent les adhérences. »
Les bonnes pratiques de Java consistent à créer des DAO (Data Access Object), qui font partis des recommandations J2EE depuis des lustres http://java.sun.com/blueprints/corej2eepatterns/Patterns/Dat(...) et les frameworks actuels dédiés aux bases comme Hibernate permettent même de rassembler toutes les requêtes dans quelques fichiers XML dédiés aux bases de données.
Donc non, actuellement la mode J2EE struts & co, les requêtes SQL ne doivent pas être éparpillés dans tout le code.
Pour PHP, par contre, les bonnes pratiques semblent effectivement lointaines, quand on n'a pas le SQL mélangé avec le HTML, on a de la chance. La lecture du code source de dotclear m'a redonné quelques espoirs.
[^]Re: PostgreSQL oui mais pas tout de suite
Je ne connais pas JDBC ( je bosse avec des DBI Perl).
Mais il existe une fonctionnalite Postgresql :
INSERT INTO ... RETERNING ...
SI ton driver te permet de faire des fetch (ce que je suppose), ca doit fonctionner !
le lien vers la doc :
http://docs.postgresqlfr.org/8.3/sql-insert.html
Linux c'est comme ...
heu ...
comme ...
c'est bien quoi !
[^]Re: PostgreSQL oui mais pas tout de suite
s/reterning/returning
Cf. la doc, c'est une extension (apparut dans la 8.2 je crois) qui n'est pas recommandée. La méthode plébiscitée consite à faire un 'select nextval(seq)/curval(seq)' où seq est le nom de la séquence utilisée (p.e. nomtable_champ_seq dans le cas d'une déclaration 'serial').