Discussion :

[Jimmy_]

Tu prends le coût de maintenance de la vue en temps réel sur chaque insert/delete/update.
A l'époque on a fait un batch de nuit pour que ce soit transparent, le contrôleur n'ayant pas besoin des données du jour.

Mais bon il faut voir au cas par cas selon l'utilisation.

[molarisapa]

Merci à tous pour vos aides.

J'ai eu plutôt l'habitude de travailler sur des applications où la base de données avait "pleins pouvoir" en abordant une place centrale et cruciale

Outre son rôle légitime de stockage de données, d'index, et son pouvoir exécutif à travers la panoplie de requêtes, elle avait aussi :

• un pouvoir de fonctionnalités métiers à travers des procédures stockées et distribuées
• un pouvoir d'adaptation et de pilotage à travers des vues
• un pouvoir conditionnelle à travers des triggers

J'ai bien aimé la citation de tchize

Croire que la base de donnée, c'est le métier, c'est faux. Aujourd'hui c'est ton application le Métier, la base n'est qu'un support à ce métier, elle doit s'y plier. On est plus à l'époque où les application sur DB se contentaient d'appeler des procédure enregistrées ou des vues pour juste les afficher. Aujourd'hui, une grande partie de la logique métier se trouve du coté de l'application.

Pour ce nouveau projet, je vais donc penser et concevoir mon système Métier autrement et le modéliser avant tout à travers les Objets/Héritage Java. Je vais aborder la SGBD comme un support à ce Métier Java.

Dans l'idéal même, ça serait de ne pas me projeter sur le support de données en me disant :
"En local, je vais développer sur du stockage en fichier xml. Mais peut-être qu'ensuite cela sera une sgbd MySql ou Postgres. Mais qu'importe, je me concentre sur ma couche métier Hibernate, le reste suivra naturellement"

(bien sur, je peux me permettre de penser comme cela, car au final, il n'y aura que 8 à 9 tables avec max 1000 enregistrements...)