Mais ça n'a rien d'incompatible avec une génération de procédures stockées! Pour l'instant les SGBDR sont encore ce que l'on a trouvé de mieux pour la persistance des objets. Autant en tirer le meilleur parti et les utiliser à bon escient.
> type hibernate qui lui gère le SQL...
Les procédures stockées aussi? Parce que si c'est pour se retrouver avec du code SQL disséminé un peu partout, merci bien, mais j'aurais l'impression de refaire les mêmes âneries qu'il y a 20 ans avec le SQL embedded dans du Cobol. Enfin, je crois qu'on a déjà eu ce débat maintes et maintes fois. Il faudrait que l'on en discute de vive voix. :)
> marre de résonner en table et requête :)
Tout à fait d'accord, et c'est justement la raison pour laquelle je trouve judicieux de faire tout celà automatiquement et le plus efficacement possible pour s'affranchir de ces contraintes. Encore que pour certains traitements, tu n'es pas près de m'ôter de l'idée que rien ne vaut de bonnes procédures SQL longuement affinées avec un analyseur de requêtes. Et là rien ne remplacera jamais un bon DBA...
[^] # Re: Un souhait
Posté par Raoul Volfoni (site web personnel) . En réponse à la dépêche Solutions Linux 2005 : Naissance de l'association PostgreSQLFr. Évalué à 1.
Mais ça n'a rien d'incompatible avec une génération de procédures stockées! Pour l'instant les SGBDR sont encore ce que l'on a trouvé de mieux pour la persistance des objets. Autant en tirer le meilleur parti et les utiliser à bon escient.
> type hibernate qui lui gère le SQL...
Les procédures stockées aussi? Parce que si c'est pour se retrouver avec du code SQL disséminé un peu partout, merci bien, mais j'aurais l'impression de refaire les mêmes âneries qu'il y a 20 ans avec le SQL embedded dans du Cobol. Enfin, je crois qu'on a déjà eu ce débat maintes et maintes fois. Il faudrait que l'on en discute de vive voix. :)
> marre de résonner en table et requête :)
Tout à fait d'accord, et c'est justement la raison pour laquelle je trouve judicieux de faire tout celà automatiquement et le plus efficacement possible pour s'affranchir de ces contraintes. Encore que pour certains traitements, tu n'es pas près de m'ôter de l'idée que rien ne vaut de bonnes procédures SQL longuement affinées avec un analyseur de requêtes. Et là rien ne remplacera jamais un bon DBA...