Discussion :

[gerbouille42]

Bonjour,
Je travaille actuellement sous Postgresql 8.3.5 avec Hibernate.
Hibernate ayant tendance à faire beaucoup de jointures, je rencontre le probleme suivant:

"ERROR: target lists can have at most 1664 entries"

Je suis conscient du problème de conception de la base de données, qui me fait en arriver là mais je n'ai malheureusement pas le choix.
Après m'être renseigné, j'ai passé le block_size à 32KB, ce qui ne change rien...

Quelqu'un aurait-il une idée pour permettre à Postgres de passer outre cette limite?

Cordialement,

Cédric.

[SQLpro]

A priori aucune possibilité de surpasser cette limite. Et si d'ailleurs il y avait ce serait au détriment particulièrement dramatique des performances...
Mais 1664 colonnes dans une requête, on pisse de rire !

C'est une des raisons pour lesquelles je déconseille fortement l'utilisation des outils de mapping RO comme Hibernate qui sont des pièges à c...

Voici un extrait d'un article que je rédige sur les concepts de développement base de données...

6 – Pourquoi pas un ORM ?

Bonne idée, mais mauvaise pioche… Les outils actuels de mapping relationnel objet, d’Hibernate à iBatis en passant par l’inabouti Entity Framework, possèdent tous les mêmes défauts. Malgré tous les caches qu’on leur met les performances sont divisées par un facteur important par rapport à une série d’insertions faites directement depuis le code client . Pire encore lorsque l’on compare ce que fait l’ORM par rapport à une procédure stockée. En sus les transactions durent plus longtemps car il faut se payer les temps de communications réseau entre les serveurs, ce qui augmente la durée des verrous sur les tables et diminue donc la capacité globale du système à absorber la charge, alors que c’est un des principaux argument de vente (cherchez l’erreur !). Enfin, peu de gens savent qu’une transaction applicative n’est pas l’équivalent d’une transaction de données et qu’il faut à la fois l’un et l’autre si l’on veut être rigoureux. Quant au pilotage du niveau d’isolation des transactions de données, comme les développeurs ne savent même pas de quoi il s’agit, on en constate généralement l’absence !
Finalement les seuls arguments positifs en faveur ce ces outils sont les suivants : pour les éditeurs, cela permet de vendre de la boîte (noire…), pour les développeurs cela leurs permet de rester dans le concept objet sans jamais aller voir du côté de la base de données, les enfonçant ainsi encore un peu plus dans leurs carences.
Quant à l’argument qui consiste à dire que la maintenabilité d’un code client est bien plus simple qu’un code relationnel, j’ose dire qu’elle est d’une évidente stupidité : avoir 3 à 4 fois moins de lignes de code en matière relationnelle qu’avec du code itératif induit mathématiquement le fait qu’il y aura proportionnellement moins d’intervention à y faire. De plus la maintenance d’un service se fait à froid, alors que dans la base c’est nativement à chaud. Bref l’argument de facilité de maintenance largement répandu, montre encore une fois l’étendu du désastre culturel : pour avoir, par manque de formation, laissé les développeurs dans l’ignorance des possibilités de codage dans un SGBDR, pour avoir parfois choisit les mauvais outils (MySQL, SQLite…) on a contourné le problème en y ajoutant des couches superflues, alambiquées et coûteuses, tant en licence, qu’en temps de développement ou en administration.

###

Figure 2 : historique de la montée en puissance des SGBDR et leur contre utilisation
(© Toon Koppelaars)

Toon Koopelars nous donne ce graphique si pertinent (figure 2). On y voit les possibilités des SGBDR croîtrent de façon exponentielle, tandis que leur utilisation commence à décroître brusquement avec la mode d’utilisation de certains outils comme les ORM ou l’arrivée de SGBD pseudo relationnels…

Le seul moyen est de revoir entièrement votre conception.

A +