Bon d'accord, mais tu es en contradiction avec ton autre thread, si le stockage donnes tu t'en fous.
Tu n'es heureusement pas oblige d'utiliser un SGBDO.
Neanmoins, le plus rapide est sans doute de passer par un stockage specialise style SGBDO ou systeme de stockage dedie a Java, parceque ca a de bonnes chances d'etre plus rapide et d'enlever pas mal de couches (quel interet de generer du SQL, de l'interpreter et de gerer tout ces bidules relationnels, si ton gestionnaire de donnees passe directement par la reflexion pour savoir quoi stocker, gere les transactions au niveau de Java et te laisse les mains libres).
Mais en fait ton utilisation d'un SGBDR est tout a fait minimaliste, s'en passerai sans doute aisement. Le SGBDR dans l'usage que tu decris est a peine plus qu'un filesystem en reseau (ok je grossi le trait). Du coup il est normal que les fonctionnalites "avancees" des SGBDR te semblent gadgets puisque tu fais plutot les choses cote 2eme tiers (sauf des stored procedure..... n'est-ce pas mal de descendre la logique metier dans la base ? :-p ).
Ca n'est vraiment pas l'usage le plus efficace que l'on puisse faire de ces outils extraordinaires que sont les SGBD modernes.
Bref, je radote, mais ce que tu as leve c'est une vieille hache de guerre entre les tenants du SGBDR comme element d'infrastructure a peine plus intelligent qu'un filesystem et les amateurs d'intelligence dans la BDD (et pas forcement en stored procedures, mais par exemple en contraintes, valeurs pas defaut, types evolues, ...).
[^] # Re: Et mysql
Posté par Christophe Renard . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 2.
Tu n'es heureusement pas oblige d'utiliser un SGBDO.
Neanmoins, le plus rapide est sans doute de passer par un stockage specialise style SGBDO ou systeme de stockage dedie a Java, parceque ca a de bonnes chances d'etre plus rapide et d'enlever pas mal de couches (quel interet de generer du SQL, de l'interpreter et de gerer tout ces bidules relationnels, si ton gestionnaire de donnees passe directement par la reflexion pour savoir quoi stocker, gere les transactions au niveau de Java et te laisse les mains libres).
Mais en fait ton utilisation d'un SGBDR est tout a fait minimaliste, s'en passerai sans doute aisement. Le SGBDR dans l'usage que tu decris est a peine plus qu'un filesystem en reseau (ok je grossi le trait). Du coup il est normal que les fonctionnalites "avancees" des SGBDR te semblent gadgets puisque tu fais plutot les choses cote 2eme tiers (sauf des stored procedure..... n'est-ce pas mal de descendre la logique metier dans la base ? :-p ).
Ca n'est vraiment pas l'usage le plus efficace que l'on puisse faire de ces outils extraordinaires que sont les SGBD modernes.
Bref, je radote, mais ce que tu as leve c'est une vieille hache de guerre entre les tenants du SGBDR comme element d'infrastructure a peine plus intelligent qu'un filesystem et les amateurs d'intelligence dans la BDD (et pas forcement en stored procedures, mais par exemple en contraintes, valeurs pas defaut, types evolues, ...).