Cela manque de précision, je le concède ;) Le plus simple est de prendre un exemple. Actuellement, je suis sur une application qui évolue tout le temps (car les besoins changent, le cadre d'application, la loi, etc...). Il m'arrive de devoir faire des modifications au niveau du schéma de la BD afin justement de pouvoir prendre en compte ces besoins futurs (qui ne vont pas tarder à arriver), mais qui ne sont pas encore développés. Je peux ainsi mettre à jour petit à petit l'application, souvent, et sans difficulté. C'est très pratique pour pouvoir la tester en condition réelle (je fais bien entendu des tests avant ! Mais les meilleurs testeurs restent les utilisateurs).
C'est la couche métier qui fait ce boulot chez moi (la DAO si tu préfère).
Quant aux triggers, je suis étonné de te le voir mentionner. Car si pour toi l'utilisation des procédures stockées mérite d'être pendu haut et court, que dire de l'utilisation des triggers ? C'est le truc le plus discret qui soit ! Discret dans le sens où ce sont des actions qui sont faite de manière implicite en réponse à un événement, contrairement aux procédures stockées qui sont appelées explicitement.
Tout est dans la parenthèse « en se limitant à coder des invariants ». Il s'agit uniquement de faire péter une erreur en cas de modification foireuse de tes données. Tu ne fais que valider la cohérence de tes données rien de plus.
Ce qui a un impact sur l'architecture en place (je pense à la configuration du serveur notamment).
Pas forcément autant que tu ne semble le croire. Je suis entrain de m'amuser avec vertx. Pour faire de l'event sourcing. Pour le moment c'est juste une application java multithreadé avec un mongodb et un hazelcast (embarqué). Donc le tout avec un seul serveur. Puis gérer une distribution du système uniquement par configuration et ainsi être capable de monter en charge via la multiplication de serveur spécifique et utiliser le bus d'événement que j'utilise déjà pour faire le job.
C'est peut être la volumétrie qui augmente si tu as beaucoup d'événements qui modifie des données existante. Tu peut optimiser ça par un batch qui va agréger tes données (il suffit que ça fréquence soit inférieure au temps que tu métrais pour détecter le bug).
Dans l'autre sens, tu as beaucoup de cas où tu cherche une traçabilité totale de tes données, là tu l'a de base. :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Facile!
Posté par barmic . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 2.
C'est la couche métier qui fait ce boulot chez moi (la DAO si tu préfère).
Tout est dans la parenthèse « en se limitant à coder des invariants ». Il s'agit uniquement de faire péter une erreur en cas de modification foireuse de tes données. Tu ne fais que valider la cohérence de tes données rien de plus.
Pas forcément autant que tu ne semble le croire. Je suis entrain de m'amuser avec vertx. Pour faire de l'event sourcing. Pour le moment c'est juste une application java multithreadé avec un mongodb et un hazelcast (embarqué). Donc le tout avec un seul serveur. Puis gérer une distribution du système uniquement par configuration et ainsi être capable de monter en charge via la multiplication de serveur spécifique et utiliser le bus d'événement que j'utilise déjà pour faire le job.
C'est peut être la volumétrie qui augmente si tu as beaucoup d'événements qui modifie des données existante. Tu peut optimiser ça par un batch qui va agréger tes données (il suffit que ça fréquence soit inférieure au temps que tu métrais pour détecter le bug).
Dans l'autre sens, tu as beaucoup de cas où tu cherche une traçabilité totale de tes données, là tu l'a de base. :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)