je peux mettre à jour le schéma de ma BD sans impacter ma couche métier ;
Ce qui n'a pas de sens. Enfin... Pas dans le sens que tu l'indique. Soit changer ton modèle a des implications métier (ça arrive forcément), soit ça impact uniquement ta couche persistance (quand tu travail en couche).
ma couche métier gagne en lisibilité, dans la mesure où les opérations les plus complexes sont réalisées en BD ;
Je ne vois pas comment tu peux avoir une opération complexe qui ne fais pas partie de ta logique métier... Tu peux parler d'un code purement technique qui serait de la tambouille de données, par exemple faire une projection ou des statistiques sur tes données, mais ça je ne le ferrais jamais dans une procédure stockée. Le faire dans un code à toi, ça permet de le distribuer, de le lancer en mode batch, de l'envoyer dans un job hadoop/spark/storm,... Mais aussi de le tester avec tes outils de tests unitaires classiques.
les opérations complexes en BD utilisent moins de ligne de code que leur équivalent dans ma couche métier. Je gagne encore en maintenabilité. Sans compter les gains de performance.
AMHA garder le même langage que sur le reste de l'application, ainsi que le même protocole de test est bien plus efficace pour maintenir ce code.
la BD se suffit a elle-même pour sa compréhension. Pas besoin d'aller lire le code de la couche métier. On gagne encore en maintenabilité.
C'est là que je vois que j'ai beaucoup évolué ces dernières années (pas forcément en bien). J'étais aussi de ton avis avant. Aujourd'hui, je ne vois pas l'intérêt d'avoir une « base de données qui se suffit à elle-même ». Ta base de données est faites pour soutenir une application et pas pour la beauté du geste.
ma BD est garante de la cohérence de mes données. Si une opération complexe peut remettre en cause la cohérence de mes données, elle sera présente dans ma BD et non dans ma couche métier. Ma BD définie ainsi des opérations atomiques ;
Euh... tu as tes contraintes d'intégrité pour ça et si ça ne suffit vraiment pas tu as des triggers qui peuvent faire le boulot. Je suis pas grand fan, mais si vraiment tu veux de la cohérence forte c'est une possibilité (en se limitant à coder des invariants).
ma couche métier est une interface d'accès à mes données, en offrant des services de haut niveau. Un bogue dans ma couche métier ne remet pas en cause la cohérence de mes données. Et ça, c'est super important !
Et il est impossible d'avoir de bug dans une procédure stockée ? :)
On oublie souvent qu'aujourd'hui, plus qu'une application, ce qui est important, ce sont les données. Une application, cela se développe, cela se créer. Les données, il faut du temps pour les récolter... Alors quand il faut les réparer... (si cette opération est possible, ce qui n'est pas toujours le cas).
Si j'en suis vraiment là, je préfère partir sur de l'event sourcing. Mes données sont immutables. Je reçois les données, je les stocke et ensuite je vois comment les organiser pour les rendre utilisable (sans toucher le premier stockage des données). C'est résilient (je peux reconstruire mes projections à tout moment), ça évolue très facilement et c'est facilement distribuable.
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é à 1.
Ce qui n'a pas de sens. Enfin... Pas dans le sens que tu l'indique. Soit changer ton modèle a des implications métier (ça arrive forcément), soit ça impact uniquement ta couche persistance (quand tu travail en couche).
Je ne vois pas comment tu peux avoir une opération complexe qui ne fais pas partie de ta logique métier... Tu peux parler d'un code purement technique qui serait de la tambouille de données, par exemple faire une projection ou des statistiques sur tes données, mais ça je ne le ferrais jamais dans une procédure stockée. Le faire dans un code à toi, ça permet de le distribuer, de le lancer en mode batch, de l'envoyer dans un job hadoop/spark/storm,... Mais aussi de le tester avec tes outils de tests unitaires classiques.
AMHA garder le même langage que sur le reste de l'application, ainsi que le même protocole de test est bien plus efficace pour maintenir ce code.
C'est là que je vois que j'ai beaucoup évolué ces dernières années (pas forcément en bien). J'étais aussi de ton avis avant. Aujourd'hui, je ne vois pas l'intérêt d'avoir une « base de données qui se suffit à elle-même ». Ta base de données est faites pour soutenir une application et pas pour la beauté du geste.
Euh... tu as tes contraintes d'intégrité pour ça et si ça ne suffit vraiment pas tu as des triggers qui peuvent faire le boulot. Je suis pas grand fan, mais si vraiment tu veux de la cohérence forte c'est une possibilité (en se limitant à coder des invariants).
Et il est impossible d'avoir de bug dans une procédure stockée ? :)
Si j'en suis vraiment là, je préfère partir sur de l'event sourcing. Mes données sont immutables. Je reçois les données, je les stocke et ensuite je vois comment les organiser pour les rendre utilisable (sans toucher le premier stockage des données). C'est résilient (je peux reconstruire mes projections à tout moment), ça évolue très facilement et c'est facilement distribuable.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)