Gestion de grands volumes de données - procédures stockées ou jeux de données ou autres ...?

Question

J'ai une application qui importe de gros volumes de données quotidiennement, plusieurs centaines de milliers d'enregistrements.
Les données proviennent de différentes sources. Les données sont lues à l'aide de C#, puis insérées en masse dans la base de données.

Ces données sont ensuite traitées:

• tables différentes sont liées
• nouvelles tables sont générées
données
• est corrigée en utilisant algorithmns complexes (tous les résultats de certains tableaux ont un total de zéro)

La plupart de ce traitement est effectué dans des procédures stockées.
Bien que certains du traitement complexe serait plus simple en C#, l'extraction des données dans un ensemble de données et sa réinjection ralentirait considérablement les choses.
Vous pouvez demander pourquoi je ne traite pas les données avant de l'insérer dans la base de données, mais je ne pense pas qu'il pratique à manipuler 100,000s d'enregistrements en mémoire, et les commandes SQLs définies en fonction lors de la création aider beaucoup de disques.

Cela va sans doute susciter la vieille question de l'utilisation des procédures stockées et leurs avantages et inconvénients. (Par exemple, comment testez-vous les procédures stockées?)

Ce que je voudrais en réponse, c'est votre expérience avec de gros volumes de données et comment vous avez résolu le problème.

Answer 1

J'utiliser SSIS ou DTS (en supposant que vous parlez MSSQL). Ils sont faits à cette fin et travaillent avec les PS si vous en avez besoin.

Une autre option consiste à prétraiter les données à l'aide de Perl. Même si cela ressemble à une suggestion bizarre, Perl est en réalité extrêmement rapide dans ces scénarios. Je l'ai utilisé dans le passé pour traiter des milliards d'enregistrements dans un délai raisonnable (c'est-à-dire des jours au lieu de semaines).

En ce qui concerne « Comment les procédures de l'unité magasin de test », vous unité de les tester avec MBUnit comme toute autre chose. Un petit conseil: la configuration et la restauration des données peuvent être difficiles, vous pouvez utiliser une transaction DTS ou des instructions SQL explicites.

Answer 2

j'aurais généralement d'accord avec Skliwz quand il s'agit de faire les choses dans MSSQL. SSIS et DTS sont la voie à suivre, mais si vous n'êtes pas familier avec ces technologies, elles peuvent être fastidieuses à utiliser. Cependant, il existe une alternative qui vous permettra de faire le traitement en C#, et toujours garder vos données à l'intérieur de SQL Server.

Si vous pensez vraiment que le traitement serait plus simple en C#, alors vous pouvez vouloir utiliser SQL Server Project pour créer database objects using C#. Il y a beaucoup de choses vraiment puissantes que vous pouvez faire avec des objets CLR dans SQL Server, et cela vous permettra d'écrire et l'unité tester le code avant qu'il ne touche jamais la base de données. Vous pouvez tester votre code CLR à l'intérieur de VS en utilisant l'un des frameworks de tests unitaires standard (NUnit, MSTest), et vous n'avez pas besoin d'écrire un tas de scripts de configuration et de démontage qui peuvent être difficiles à gérer.

En ce qui tester vos procédures stockées je regarderais honnêtement dans DBFit pour cela.Votre base de données ne doit plus être un trou noir de fonctionnalité non testée :)

Answer 3

Le traitement des données dépend beaucoup de ce que vous faites. Si vous avez besoin, par exemple, d'éliminer les données que vous ne voulez pas dans votre base de données, vous devez les traiter dans votre code C#. Cependant, les données à traiter dans la base de données devraient généralement être des données qui devraient être «agnostiques de mise en œuvre». Donc, si quelqu'un d'autre veut insérer des données depuis un client Java, la base de données devrait pouvoir rejeter les mauvaises données. Si vous mettez cette logique dans votre code C#, le code Java ne le saura pas. Certaines personnes objectent et disent "mais je n'utiliserai jamais une autre langue pour la base de données!" Même si c'est vrai, vous aurez toujours des administrateurs de bases de données ou des développeurs travaillant avec la base de données et ils feront des erreurs si la logique n'est pas là. Ou votre nouveau développeur C# essaiera de pousser dans les données et de ne pas connaître (ou simplement ignorer) les pré-processeurs de données écrits en C#. En bref, la logique que vous placez dans votre base de données devrait être suffisante pour garantir que les données sont correctes sans dépendre de logiciels externes.