manipulations par lots pour l'application Web en ligne

Question

Un client dispose d'un système de gestion des stocks basé sur le Web. Le système est propriétaire et compliqué. il a environ 100 tables dans la DB et des relations complexes entre eux. il a ~ 1500000 articles.

Le client effectue des réorganisations dans ses processus et a maintenant besoin de faire des mises à jour massives et de manipuler les données (seulement des changements de données, pas de changements structurels). Les écrans en ligne ne permettent pas un tel travail, car ils ont été conçus au début sans cette exigence à l'esprit. La base de données est MS Sql 2005 et l'application est un asp.net s'exécutant sur IIS. Une solution consiste à construire pour lui de nouveaux écrans où il pourrait visualiser les données dans des grilles et faire le travail requis sur une grande quantité d'enregistrements. Cela nous permettra d'utiliser les fonctions déjà existantes qui traitent des éléments uniques (il suffit d'implémenter une boucle). À ce moment, le client est conscient de deux types de manipulations massives qu'il veut faire, mais il dit qu'il y en aura d'autres. Cela exigera la conception, le codage et le test chaque fois que nous avons une demande.

Cependant, les besoins des clients sont urgents en raison de certaines exigences réglementaires, donc je me demande s'il serait plus efficace d'utiliser une sorte de mappage entre MSSQL et Excel ou Access pour exposer les informations nécessaires. Apportez les modifications dans Excel ou Access puis sauvegardez dans la base de données. peut-être utiliser SSIS pour ce faire. Je ne suis pas familier avec SSIS ou d'autres technologies qui font de telles choses, c'est pourquoi je ne suis pas en mesure de juger si la deuxième solution est effectivement efficace et meilleure que la première. Bien sûr, la deuxième solution nécessitera du travail et des tests, mais sera-t-elle plus rapide et moins coûteuse? L'autre question est: Y a-t-il d'autres moyens de le faire?

toute idée sera grandement appréciée.

Answer 1

De toute façon, vous aurez besoin de tests.

Dites que vous exportez des produits 40000 vers Excel, il les réorganise, puis vous les ramenez dans une ou plusieurs tables de transfert et applique les modifications à vos tables SQL. Comme Excel est fondamentalement un système libre, que se passe-t-il s'il introduit des situations invalides? Votre mise à jour devra le détecter, l'échouer et l'annuler ou le gérer d'une manière spécifique.

Quoi qu'il en soit, vos suggestions peuvent être rendues utilisables. Personnellement, pour les grands changements comme celui-ci, je préfère avoir un développeur de base de données expérimenté développer les changements en SQL direct (codé en dur ou piloté par table), tester sur des données de production dans un environnement de test. avant et après) et déployer le même script en production. Cela permet également l'utilisation des procédures stockées existantes (vous utilisez des SP, pour appliquer une interface cohérente à cette base de données complexe, n'est-ce pas?) Afin que la logique de base de données déjà en place soit simplement réutilisée.

Answer 2

Je doute qu'Excel puisse traiter des éléments/lignes de 1,5 mil.

Lorsque vous dites de visualiser des données dans des grilles - comment votre client apportera-t-il des changements? Manuellement ou y a-t-il une automatisation? J'encourage fortement l'automatisation (puisque vous ne connaissez que 2 types de changements pour le moment). Peut-être même une simple application "convertisseur" autonome - ne font pas partie du programme principal - il sera trop tentant pour eux de modifier manuellement les données directement dans les tables de DB.

Answer 3

Voici une stratégie qui, je pense, vous mènera de A à B dans les plus brefs délais.

une solution consiste à construire pour lui de nouveaux écrans où il pourrait visialize les données dans les réseaux et faire le travail nécessaire sur une grande quantité d'enregistrements.

Il est rarement une bonne idée de construire une interface dans le système principal que vous n'utiliserez qu'une ou deux fois. Cela prend plus de temps et vous passerez probablement plus de temps à le maintenir qu'à l'utiliser.

Cela nous permettra d'utiliser les fonctions déjà existantes qui traitent éléments simples (nous avons juste besoin mettre en œuvre une boucle)

Hack ensemble votre propre merdique petite interface dans un .NET Application, dont le seul but est de remplir cette tâche. Gardez-le dans votre dossier "stuff je pourrais utiliser plus tard". Étant donné que vous avez affaire à des volumes de données aussi importants, assurez-vous de ne pas utiliser votre application depuis un emplacement distant.

Obtenez une copie de SQL 2005 et installez-la sur une couche de virtualisation. Copiez votre base de données de production sur ce serveur SQL virtualisé. Prenez une photo de votre copie virtualisée avant de commencer à tester. Rédigez et testez votre application par rapport à cette copie virtualisée. Revenez à votre cliché instantané d'origine chaque fois que vous testez. Continuez à modifier votre code, à tester et à revenir en arrière jusqu'à ce que votre application puisse effectuer les modifications souhaitées sans problème. Ensuite, lorsque le moment est venu de changer la base de données de production, vous pouvez vous asseoir et vous détendre pendant que votre application effectue toutes les modifications. Étant donné que le processus prendra probablement un certain temps, ajoutez un peu de journalisation afin de pouvoir vérifier l'état à mesure qu'il s'exécute.

Oh oui, assurez-vous d'avoir une nouvelle sauvegarde avant d'exécuter votre grosse mise à jour.