Traitement complexe dans les procédures stockées Application Vs .net

Question

Nous construisons une nouvelle application en .net 3.5 avec la base de données du serveur SQL. La base de données est assez grande avec environ 60 tables avec des charges sur les données. L'application .net dispose de fonctionnalités permettant d'importer des données dans cette base de données à partir de la saisie de données et de systèmes tiers. Une fois toutes les données disponibles dans la base de données, le système doit faire beaucoup de calculs. La logique de calcul est assez complexe. Toutes les données requises pour les calculs sont dans la base de données et la sortie doit également être stockée dans la base de données. La collecte de données aura lieu chaque semaine et le calcul doit être effectué chaque semaine pour générer les rapports requis.

En raison du scénario ci-dessus, je pensais faire tous ces calculs en utilisant la procédure stockée. Le problème est que nous avons également besoin d'indépendance des données et que la procédure stockée ne sera pas en mesure de nous fournir cela. Mais si je fais tout cela dans .net par base de données de requêtes tout le temps, je ne pense pas qu'il sera en mesure de terminer le travail rapidement. Par exemple, j'ai besoin d'interroger une table qui me renverra 2000 lignes puis pour chaque ligne j'ai besoin d'interroger une autre table qui me renverra 300 résultats que pour chaque ligne de ceci j'ai besoin d'interroger plusieurs tables (environ 10) pour obtenir les données requises, faites le calcul et stockez la sortie dans une autre table.

Maintenant ma question devrais-je aller de l'avant avec la solution de procédure stockée et oublier l'indépendance de la base de données puisque la performance est importante. Je pense également que le temps de développement sera beaucoup moins si nous utilisons la solution de procédure stockée. Si un client souhaite cette solution sur une base de données Oracle (car il ne souhaite pas conserver une autre base de données), nous portons les procédures stockées dans la base de données Oracle et conservons deux versions pour les modifications/améliorations futures. De même, d'autres clients peuvent demander d'autres bases de données.

---

Les 2000 lignes que j'ai mentionnées ci-dessus sont des produits de skus. Les 300 lignes que j'ai mentionnées sont des attributs différents que nous voulons calculer, par ex. Les 10 tables que j'ai mentionnées contiennent des informations sur la conversion des devises, la conversion des unités, le réseau, la zone, la société, le prix de vente, le nombre de pièces vendues par jour, etc. objectif d'analyse et de rapport. L'objectif est d'obtenir des informations minutieuses sur le produit afin que l'on sache quel attribut d'une vente de produit nous coûte de l'argent et où nous pouvons faire l'amélioration.

Answer 1

Je ne considérerais pas la manipulation de données ailleurs que dans la base de données.

la plupart des gens essaient de travailler avec des données de base de données en utilisant des algorithmes de bouclage. Si vous avez besoin d'une vitesse réelle, pensez à vos données sous la forme d'un ensemble de lignes et vous pouvez mettre à jour des milliers de lignes dans une seule mise à jour. J'ai réécrit tant de boucles de curseurs écrites par des programmeurs novices dans des instructions de mise à jour uniques où le temps d'exécution a été massivement amélioré.

vous dites:

J'ai besoin d'interroger une table qui me retourner 2000 lignes puis pour chaque ligne je dois interroger une autre table qui va me retourner 300 résultats que pour chaque ligne de ce que je dois interroger plusieurs tables (environ 10) pour obtenir les données nécessaires

de votre question, il semble que vous n'utilisez pas les jointures, et vous êtes déjà pensé dans les boucles. Même si vous avez l'intention de faire une boucle, il est préférable d'écrire une requête pour joindre toutes les données nécessaires, puis faites une boucle dessus. rappelez-vous que les instructions de mise à jour et d'insertion peuvent avoir des requêtes extrêmement complexes les pilotant. inclure dans les instructions CASE, les tables dérivées, les jointures conditionnelles (LEFT OUTER JOIN) et vous pouvez à peu près résoudre n'importe quel problème dans une seule mise à jour/insertion.

Answer 2

Bien sans aucun détail spécifique sur les données que vous avez dans ces tableaux, un simple calcul indique que vous parlez de traiter plus de 6 millions de lignes d'informations dans l'exemple fourni (2 000 lignes * 300 lignes) * (1 rangée * 10 tables)).

Toutes ces lignes sont-elles distinctes ou les 10 tables de recherche ont-elles une cardinalité relativement faible? En d'autres termes, serait-il possible de créer un programme contenant les informations des 10 tables de recherche en mémoire, puis de traiter le jeu de 300 résultats en mémoire pour effectuer les calculs?

En outre, je m'inquiéterais de l'évolutivité - si vous faites cela dans une procédure stockée, il est garanti qu'il s'agit d'un processus série limité par la vitesse du serveur de base de données unique. Si vous avez la possibilité de plusieurs copies d'un programme client, chacune traitant un bloc de l'ensemble initial de 2000 enregistrements, vous pouvez effectuer certains calculs en parallèle, ce qui accélérera peut-être le temps de traitement global et le rendra évolutif. votre jeu d'enregistrements initial est 10 fois plus grand.

Answer 3

La programmation de choses comme le code de calcul a tendance à être plus facile et plus facile à maintenir en C#. En outre, le fait de limiter au minimum le traitement sur SQL Server est une bonne pratique, car la base de données est la plus difficile à mettre à l'échelle.Cela dit, d'après votre description, il semble que l'approche de procédure stockée est la voie à suivre. Lorsque le code de calcul dépend de gros volumes de données, il est plus coûteux de déplacer les données du serveur pour le calcul. Donc, sauf si vous avez des moyens raisonnables d'optimiser les données dépendantes (telles que les tables de recherche de mise en cache?), Alors vous allez probablement trouver plus pénible alors il vaut la peine de ne pas utiliser un proc stocké.

Answer 4

Les procédures stockées à chaque fois, mais comme KM a dit dans ces procédures stockées garder les itérations au minimum c'est-à-dire utiliser des jointures dans votre SQL, les bases de données relationnelles sont si bon à joindre.

L'évolutivité de la base de données sera un petit problème, d'autant plus que vous devriez effectuer ces calculs dans un processus batch.

L'indépendance de la base de données n'existe pas, à l'exception des applications CRUD les plus triviales, si votre exigence initiale est d'utiliser tout cela avec SQL Server, puis de tirer parti des outils fournis par le SGBDR. beaucoup d'argent dessus). Si (et c'est un gros if), un client suivant ne veut vraiment pas utiliser SQL Server, alors vous devrez le mordre et le coder dans une autre saveur de procédure stockée. Mais alors que vous avez identifié: "si je fais tout cela dans .net par base de données de requêtes tout le temps, je ne pense pas qu'il sera en mesure de terminer le travail rapidement." vous avez différé le coût de le faire jusqu'à ce que si et quand nécessaire.

Answer 5

Je envisagerais de le faire dans SQL Server Integration Services (SSIS). Je mettrais les calculs dans SSIS, mais laisserais les requêtes en tant que procédures stockées. Cela vous fournirait une indépendance de base de données - SSIS peut traiter des données à partir de n'importe quelle base de données avec une connexion ODBC - ainsi que des performances élevées. Seules les instructions SELECT simples seraient dans des procédures stockées et ce sont les parties de la norme SQL les plus susceptibles d'être identiques entre plusieurs produits de base de données (en supposant que vous respectiez les formes standard de requête).