Le cas d'usage que tu décris c'est de la logique métier pour preuve tu explique que c'est des choses demandé par la direction. Un code pas métier c'est un code qui ne touche pas au besoin fonctionnel de l'application (performance, robustesse, etc).
Il y a d'autres choix que les 3 que tu donne. Par exemple tu peux gérer ça via des batch ou monter une architecture lambda si tu a besoin de temps réelle et tu as tout un tas d'organisation possibles qui vont plus ou moins impacter ton design en fonction des besoins que tu as.
Choix 3) Des jeux de procédures stockées et de fonctions (et autres, en postgresql le DO INSTEAD est surpuissant si bien utilisé) qui vont être utilisés comme des vues par le client de reporting - mais qui centralisent le code en un point et simplifient grandement la maintenance.
J'aurais vraiment peur de cette solution. Comment ça se comporte avec un million de ligne ? 100 millions ? Si ta base est en cluster (est-ce distribué ? Est-ce que tu perçois clairement ce qui va entraîner une réduction de tes données ? Quelle est la granularité de lock que tu met sur tes données) ? Faire des traitement de plusieurs secondes sur une base (qui doit déjà prendre la charge de la production) ça me semble pas être une excellente idée.
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.
Le cas d'usage que tu décris c'est de la logique métier pour preuve tu explique que c'est des choses demandé par la direction. Un code pas métier c'est un code qui ne touche pas au besoin fonctionnel de l'application (performance, robustesse, etc).
Il y a d'autres choix que les 3 que tu donne. Par exemple tu peux gérer ça via des batch ou monter une architecture lambda si tu a besoin de temps réelle et tu as tout un tas d'organisation possibles qui vont plus ou moins impacter ton design en fonction des besoins que tu as.
J'aurais vraiment peur de cette solution. Comment ça se comporte avec un million de ligne ? 100 millions ? Si ta base est en cluster (est-ce distribué ? Est-ce que tu perçois clairement ce qui va entraîner une réduction de tes données ? Quelle est la granularité de lock que tu met sur tes données) ? Faire des traitement de plusieurs secondes sur une base (qui doit déjà prendre la charge de la production) ça me semble pas être une excellente idée.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)