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
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...
Sérieusement, l'exemple que je donne remplace des milliers de vues par une fonction ou procédure stockée. Les vues seraient de la logique métier selon toi ?
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.
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 ?
Mon gars qui fait du reporting je préfère grandement qu'il ait une seule connexion via une seule interface plutôt que de le voir ouvrir une connexion à la DB, une autre à l'ETL et une troisième à un datastore quelconque pour pouvoir faire ses rapports.
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.
Alors dans le désordre :
- Le lock : besoin très minime, c'est de la lecture seule. Si vraiment le besoin s'en fait sentir on peut créer un index sur un timestamp pour s'assurer que toutes les données étaient présentes à l'instant X et qu'aucune n'est arrivée en cours de route. Mais sur du reporting financier/marketing je ne pense pas que ce soit nécessaire (les chiffres de la dernière seconde intéressent peu de monde, généralement on fait ce type de reporting sur des données qui ont au moins 24h )
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.
Le partitionnement ou les cluster : Je ne vois pas de cas ou cela pourrait avoir un impact négatif. Une fois de plus un traitement par fonction ou procédure sera nécessairement meilleur qu'un traitement séquentiel par requête ou par vue. ne serait-ce que parce que lors d'un traitement par fonction la BDD peut travailler en format binaire interne tout du long et ne doit faire la conversion format de sortie des données qu'à la toute dernière étape.
La durée des traitement et la saturation des I/O BDD : 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. Pour finir il est nettement plus simple de limiter les I/O et la consomation CPU d'une procédure définie que de tous les accès possibles et imaginables à des vues et des tables.
A titre d'information j'utilise ce type de techniques sur des centaines de millions de lignes (données géométriques, ça va très vite) avec des temps de réponses de l'ordre de la milliseconde. 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.
[^] # Re: Facile!
Posté par Kaane . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 6.
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
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...
Sérieusement, l'exemple que je donne remplace des milliers de vues par une fonction ou procédure stockée. Les vues seraient de la logique métier selon toi ?
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.
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 ?
Mon gars qui fait du reporting je préfère grandement qu'il ait une seule connexion via une seule interface plutôt que de le voir ouvrir une connexion à la DB, une autre à l'ETL et une troisième à un datastore quelconque pour pouvoir faire ses rapports.
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.
Alors dans le désordre :
- Le lock : besoin très minime, c'est de la lecture seule. Si vraiment le besoin s'en fait sentir on peut créer un index sur un timestamp pour s'assurer que toutes les données étaient présentes à l'instant X et qu'aucune n'est arrivée en cours de route. Mais sur du reporting financier/marketing je ne pense pas que ce soit nécessaire (les chiffres de la dernière seconde intéressent peu de monde, généralement on fait ce type de reporting sur des données qui ont au moins 24h )
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.
Le partitionnement ou les cluster : Je ne vois pas de cas ou cela pourrait avoir un impact négatif. Une fois de plus un traitement par fonction ou procédure sera nécessairement meilleur qu'un traitement séquentiel par requête ou par vue. ne serait-ce que parce que lors d'un traitement par fonction la BDD peut travailler en format binaire interne tout du long et ne doit faire la conversion format de sortie des données qu'à la toute dernière étape.
La durée des traitement et la saturation des I/O BDD : 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. Pour finir il est nettement plus simple de limiter les I/O et la consomation CPU d'une procédure définie que de tous les accès possibles et imaginables à des vues et des tables.
A titre d'information j'utilise ce type de techniques sur des centaines de millions de lignes (données géométriques, ça va très vite) avec des temps de réponses de l'ordre de la milliseconde. 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.