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
Posté par peau chat . En réponse à la dépêche Sortie de PostgreSQL 8.3. Évalué à 5.
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.