Conversion de projet à SQL Server, pensées de conception?

Question

Actuellement, je suis assis sur une application d'affaires moche écrit dans Access qui prend une feuille de calcul sur une base bi-quotidienne et l'importe dans un MDB. Je suis en train de convertir un projet majeur qui inclut ceci dans SQL Server et .net, en particulier dans C#.

Pour stocker cette information, il y a deux tables (noms d'alias ici) que j'appellerai Master_Prod et Master_Sheet jointes sur un parent de clé d'identité à la table Master_Prod, ProdID. Il y a également deux autres tables pour stocker l'historique, History_Prod et History_Sheet. Il y a plus de tables qui s'étendent de Master_Prod mais en limitant cela à deux tables à des fins d'explication. Depuis que cela a été écrit dans Access, le sous-programme pour gérer ce fichier est jonché de déclencheurs codés manuellement pour faire face à l'histoire qui ont été et ont été une douleur constante à suivre, une raison pour laquelle je suis content que ça bouge à un serveur de base de données plutôt qu'à un outil RAD. J'écris des déclencheurs pour gérer le suivi de l'historique. Mon plan était/était de créer un objet modélisant la feuille de calcul, analyser les données dans celui-ci et utiliser LINQ pour faire quelques vérifications côté client avant d'envoyer les données au serveur ... Fondamentalement, je dois comparer les données dans le feuille à un enregistrement correspondant (à moins qu'il n'existe pas, puis son nouveau). Si l'un des champs a été modifié, je veux envoyer la mise à jour. A l'origine, j'espérais mettre cette procédure dans une sorte d'assembly CLR qui accepte une liste IEnumerable car je vais déjà avoir la feuille de calcul sous cette forme, mais j'ai récemment appris que ça va être associé à un assez important serveur de base de données que je suis très préoccupé par s'embourber.

Cela vaut-il la peine de mettre en place une procédure stockée CLR? Il y a d'autres points d'entrée où les données entrent et si je pouvais construire une procédure pour les gérer étant donné les objets passés, je pourrais retirer beaucoup de règles métier de l'application au détriment des performances potentielles de la base de données. Fondamentalement, je veux retirer la mise à jour du client et la mettre dans la base de données afin que le système de données gère si la table doit être mise à jour afin que le déclencheur d'historique puisse se déclencher.

Réflexions sur une meilleure façon de mettre en œuvre dans la même direction?

Answer 1

Utilisez SSIS. Utilisez Excel Source pour lire les feuilles de calcul, utilisez peut-être un Lookup Transformation pour détecter de nouveaux éléments et enfin utiliser un SQL Server Destination pour insérer le flux d'éléments manquants dans SQL.

SSIS est façon mieux adapté à ce genre de travaux que d'écrire quelque chose à partir de zéro, peu importe combien amusant linq est. Les paquets SSIS sont plus faciles à déboguer, à maintenir et à refactoriser que certains DLL avec des sources oubliées. En outre, vous ne serez pas en mesure de faire correspondre les raffinements que SSIS a dans la gestion de ses tampons pour un débit élevé Data Flows.

Answer 2

Au départ, je souhaitais mettre cette procédure dans une sorte de réunion CLR qui accepte une liste IEnumerable depuis que je vais avoir la feuille de calcul sous cette forme déjà, mais je l'ai récemment appris cela va être jumelé avec un serveur de base de données plutôt important que je suis très préoccupé par s'embourber.

Ne fonctionne pas. Toute entrée dans une procédure CLR écrite en C# STILL doit suivre la sémantique SQL normale. Tout ce qui peut changer est la configuration interne. Toute communication avec le client doit être faite en SQL. Ce qui signifie des exécutions/appels de méthode. Pas moyen de passer directement dans un nombre d'objets.

Answer 3

Mon plan est/était de créer un objet la modélisation de la feuille de calcul, analyser les données dans et utiliser LINQ pour faire quelques côté client vérifie avant d'envoyer les données au serveur ... Fondamentalement, je besoin pour comparer les données de la feuille à un enregistrement correspondant (à moins qu'il n'en existe, puis son nouveau). Si l'un des champs a été modifié, je veux envoyer la mise à jour .

Vous devez probablement choisir une «centricité» pour votre approche, c'est-à-dire centrée sur les données ou sur les objets.

Je modéliserais probablement les données de manière appropriée en premier. En effet, les bases de données relationnelles (ou même les modèles non normalisés représentés dans les bases de données relationnelles) survivent souvent aux applications client/bibliothèques. Je commencerais probablement à essayer de modéliser sous une forme normale et de penser aux déclencheurs pour maintenir la vérification/l'historique comme vous le mentionnez aussi pendant cette période.

Je penserais alors typiquement aux données entrant (pas vraiment un modèle d'objet ou une entité). Alors je me concentre sur le format et la sémantique des entrées et je vois s'il y a un mauvais ajustement dans mon modèle de données - peut-être y avait-il des suppositions incorrectes dans mon modèle de données. Oui, je ne pense pas à faire un modèle d'objet qui valide la feuille de calcul même si les feuilles de calcul sont des sources d'entrée notoirement inconstantes. Comme Remus, j'utiliserais simplement SSIS pour l'introduire - peut-être dans une table de mise en scène et ensuite une validation plus poussée avant de l'appliquer aux tables de production avec du T-SQL. Puis je penserais à un outil client qui avait un modèle d'objet basé sur mon bon modèle de données solide. Alternativement, l'approche objet signifierait la modélisation de la feuille de calcul, mais aussi un modèle objet qui doit être conservé dans la base de données - et peut-être vous avez maintenant deux modèles objet (tableur et domaine d'activité complet) et un modèle de base de données), si le modèle d'objet de feuille de calcul n'est pas aussi complet que le modèle d'objet de domaine métier du système.

Je peux penser à un exemple où j'avais un modèle d'objet externe jetable comme ceci. Il a lu un "fichier maître" qui était un fichier de mise en page décrivant un fichier d'entrée. Ce modèle d'objet a permis au programme de construire des paquets SSIS (et des scripts BCP et SQL) pour importer/exporter/faire d'autres opérations sur ces fichiers. Effectivement, il s'agissait d'un modèle d'objet jetable - il n'était pas utilisé comme modèle réel pour les données dans les lignes ou tout type de navigation entre les lignes parents et enfants, etc., mais simplement comme une représentation interne à des fins internes. correspondent à une entité "domaine".