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.
Je ne calcule pas mes projections d'une façon ou d'une autre, je créé des vues - il n'y a pas de calcul coté BDD. Une vue SQL par exemple c'est juste un test qui dit "si on te demande les données de TITI, renvoie à la place les données de TATA ". Et comme je n'ai pas envie de créer toutes les vues possibles et imaginables je fais une fonction à la place. Il n'y a aucun calcul spécifique métier qui est fait en base. Ce ne sont que des opérations de consolidation et d'agrégation génériques. Je n'ai rien besoin de valider avec mes utilisateurs si ce n'est l'interface qu'ils doivent utiliser. Plutôt que de leur dire tu fais
SELECT * from (
SELECT ...
UNION SELECT ...
UNION SELECT ...
UNION SELECT ...
JOIN
SELECT ...
UNION SELECT ...
...
ON ...
) WHERE month=4 GROUP BY "CLIENT", "PRODUIT" HAVING SUM("CA") > 10000
Je leur dit tu fais
SELECT * FROM fonction_aggregat(['CLIENT','PRODUIT'], '{"month":"=4", "sumca":">10000"}')
Pour la base de données il n'y a aucune différence en terme SQL, il y a un petit surcout lors de la préparation de la procédure fonction_aggregat, mais qui est négligeable et qui se rembourse largement si la procédure est appelée plus d'une fois. Le surcout du parsing est infime, les I/O sont divisés par 10 par rapport à des requêtes classiques ou des vues, je peux forcer le plan d’exécution que je veux, la priorité, le temps CPU etc.
Et une fois de plus ça ne rempli pas d'autres rôle qu'une vue.
Ç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.
Mais pourquoi j'irais créer des fonctions (ou classes) de filtrage et de présentation de données dans mon code, alors que ça va pénaliser la base de données. Si je ressors la table entière, l'impact I/O va être délirant - si je fait une partie du filtrage coté BDD (WHERE ou HAVING) pourquoi j'irais mettre le reste du filtrage dans mon appli ? Filtrer et présenter les données c'est le boulot de la base, et elle va le faire beaucoup mieux, beaucoup plus vite (surtout en BDD relationnel) que mon appli qui voit devoir commencer par tout remapper avant de pouvoir finir le boulot.
Ton code s'exécute sans demander de temps CPU ?
OUI ! Le cout CPU des procédures que je cite est nul, voire négatif par rapport à une execution SQL brute de décoffrage. La première exécution va prendre quelques pouillèmes de millisecondes en plus (et encore une très grosse procédure) - toutes les exécutions suivantes seront plus rapide et moins consommatrice de CPU que l'équivalent SQL. La BDD n'aura plus à faire le préscan, à choisir entre le bitmap scan ou le seq scan ou les index, à définir la taille des rows de sortie, à dimensionner les flux etc. Tout ce travail aura été fait lors du premier appel, et les appels suivant seront plus rapides et moins gourmands que le SQL.
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.
Les données sont en flux continue depuis plusieurs sources. C'est pas parce qu'une source change que je vais détruire toute ma base et refaire toutes mes vues.
Elles sont juste une misère à tester :)
Par rapport à des milliers de vues, ou des milliers de requètes SQL plus ou moins propres et subtilement différentes dans le code de l'appli ? Mon choix est vite fait...
[^] # Re: Facile!
Posté par Kaane . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 7.
Je ne calcule pas mes projections d'une façon ou d'une autre, je créé des vues - il n'y a pas de calcul coté BDD. Une vue SQL par exemple c'est juste un test qui dit "si on te demande les données de TITI, renvoie à la place les données de TATA ". Et comme je n'ai pas envie de créer toutes les vues possibles et imaginables je fais une fonction à la place. Il n'y a aucun calcul spécifique métier qui est fait en base. Ce ne sont que des opérations de consolidation et d'agrégation génériques. Je n'ai rien besoin de valider avec mes utilisateurs si ce n'est l'interface qu'ils doivent utiliser. Plutôt que de leur dire tu fais
SELECT * from (
SELECT ...
UNION SELECT ...
UNION SELECT ...
UNION SELECT ...
JOIN
SELECT ...
UNION SELECT ...
...
ON ...
) WHERE month=4 GROUP BY "CLIENT", "PRODUIT" HAVING SUM("CA") > 10000
Je leur dit tu fais
SELECT * FROM fonction_aggregat(['CLIENT','PRODUIT'], '{"month":"=4", "sumca":">10000"}')
Pour la base de données il n'y a aucune différence en terme SQL, il y a un petit surcout lors de la préparation de la procédure fonction_aggregat, mais qui est négligeable et qui se rembourse largement si la procédure est appelée plus d'une fois. Le surcout du parsing est infime, les I/O sont divisés par 10 par rapport à des requêtes classiques ou des vues, je peux forcer le plan d’exécution que je veux, la priorité, le temps CPU etc.
Et une fois de plus ça ne rempli pas d'autres rôle qu'une vue.
Mais pourquoi j'irais créer des fonctions (ou classes) de filtrage et de présentation de données dans mon code, alors que ça va pénaliser la base de données. Si je ressors la table entière, l'impact I/O va être délirant - si je fait une partie du filtrage coté BDD (WHERE ou HAVING) pourquoi j'irais mettre le reste du filtrage dans mon appli ? Filtrer et présenter les données c'est le boulot de la base, et elle va le faire beaucoup mieux, beaucoup plus vite (surtout en BDD relationnel) que mon appli qui voit devoir commencer par tout remapper avant de pouvoir finir le boulot.
OUI ! Le cout CPU des procédures que je cite est nul, voire négatif par rapport à une execution SQL brute de décoffrage. La première exécution va prendre quelques pouillèmes de millisecondes en plus (et encore une très grosse procédure) - toutes les exécutions suivantes seront plus rapide et moins consommatrice de CPU que l'équivalent SQL. La BDD n'aura plus à faire le préscan, à choisir entre le bitmap scan ou le seq scan ou les index, à définir la taille des rows de sortie, à dimensionner les flux etc. Tout ce travail aura été fait lors du premier appel, et les appels suivant seront plus rapides et moins gourmands que le SQL.
Les données sont en flux continue depuis plusieurs sources. C'est pas parce qu'une source change que je vais détruire toute ma base et refaire toutes mes vues.
Par rapport à des milliers de vues, ou des milliers de requètes SQL plus ou moins propres et subtilement différentes dans le code de l'appli ? Mon choix est vite fait...