GNI ? L'exemple que je donne c'est la réponse à un besoin exprimé par la direction au niveau base de données. La base de données elle même a probablement été créé pour répondre à un besoin exprimé par la direction (ou autre). Ça revient à dire que toute base de données qui sert à quelque chose au niveau fonctionnel serait en fait de la logique métier...
Tes utilisateurs se foutent de ta base. Si ta base consiste à écrire sur du papier tes données, c'est pas leur problème (tant que ça répond aux contrainte que l'on te donne).
Le code métier c'est celui qui répond à une problématique métier. C'est pointé directement par une User Storie. Le code non métier c'est celui qui consiste à traduire tes dates en timestamp parce que tu préfère les stocker comme ça.
Ici le fait que tu calcul tes projections dans une direction ou dans une autre ça impact directement tes utilisateurs. C'est donc quelque chose que tu dois valider avec les utilisateurs ça concerne leur métier.
Si tu décide de passer à du stockage en fichier XML. Cette traduction en XML ce n'est pas métier, l'utilisateur se fout de savoir si tu stocke du XML ou autre chose ça ne va pas changer sa façon de travailler.
C'est plus clair ?
Pourquoi j'irai compliquer mon architecture, rajouter des scripts ou des datastore à droite à gauche si je n'en ai pas besoin ? Tu te plains plus haut de la dispersion des éléments logiques entre plusieurs endroits et ta solution consiste à disperser les éléments data à la place ?
Ça ne demande rien de tout ça. Ça demande à créer des classes/fonctions en plus oui. Le reste est uniquement dépendant de ton besoin. Ce n'est pas parce que tu organise ton code pour qu'il soit distribuable qu'il faut le distribuer.
La tenue de charge en cas de forte demande/grosse quantité de données : Ce sera la même que celle de la base SQL ou NoSQL sous-jacente. Peut importe que ce soit via fonction, vue ou cube OLAP virtuel, si la base de données ne peut pas encaisser la charge d'une façon il y a peu de chance qu'elle puisse l'encaisser d'une autre. Et encore les fonctions et procédures seront plus performantes que les deux autres méthodes.
Ton code s'exécute sans demander de temps CPU ? Le faire exécuter l'algo sur un autre service, ça permet de réduire la charge CPU consommée par ta base (et donc de lui laisser faire ce qu'elle fait de mieux : les IO) et du peux lisser la charge que tu impose à ta base via de la backpressure.
Une fois de plus les fonctions et procédures ne peuvent qu'améliorer l'existant sans rien bloquer autour. En plus on peut parfaitement faire une base dédiée reporting (donc sans impact sur la prod) et utiliser des procédures quand même sur cette base.
Quel est l'intérêt ? Tu peux calculer tes projections lors de l'alimentation de cette base. Si un changement de besoin interviens, tu peut détruire ta base de reporting et la reconstruire avec tes nouvelles projections.
C'est un problème de design de base de données et de placement des index - l'utilisation ou non des procedures stockées n'a pas grande influence sur le résultat final.
Elles sont juste une misère à tester :)
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é à 3.
Tes utilisateurs se foutent de ta base. Si ta base consiste à écrire sur du papier tes données, c'est pas leur problème (tant que ça répond aux contrainte que l'on te donne).
Le code métier c'est celui qui répond à une problématique métier. C'est pointé directement par une User Storie. Le code non métier c'est celui qui consiste à traduire tes dates en timestamp parce que tu préfère les stocker comme ça.
Ici le fait que tu calcul tes projections dans une direction ou dans une autre ça impact directement tes utilisateurs. C'est donc quelque chose que tu dois valider avec les utilisateurs ça concerne leur métier.
Si tu décide de passer à du stockage en fichier XML. Cette traduction en XML ce n'est pas métier, l'utilisateur se fout de savoir si tu stocke du XML ou autre chose ça ne va pas changer sa façon de travailler.
C'est plus clair ?
Ça ne demande rien de tout ça. Ça demande à créer des classes/fonctions en plus oui. Le reste est uniquement dépendant de ton besoin. Ce n'est pas parce que tu organise ton code pour qu'il soit distribuable qu'il faut le distribuer.
Ton code s'exécute sans demander de temps CPU ? Le faire exécuter l'algo sur un autre service, ça permet de réduire la charge CPU consommée par ta base (et donc de lui laisser faire ce qu'elle fait de mieux : les IO) et du peux lisser la charge que tu impose à ta base via de la backpressure.
Quel est l'intérêt ? Tu peux calculer tes projections lors de l'alimentation de cette base. Si un changement de besoin interviens, tu peut détruire ta base de reporting et la reconstruire avec tes nouvelles projections.
Elles sont juste une misère à tester :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)