Converting project to SQL Server, pensées de design?

Question

Actuellement, je travaille sur une application métier moche écrite en Access qui prend une feuille de calcul sur une base bi-quotidienne et l'importe dans un fichier MDB. Je suis en train de convertir un projet majeur qui inclut ceci en SQL Server et .net, plus précisément en c#.

Pour stocker ces informations, il y a deux tables (noms d'alias ici) que j'appellerai Master_Prod et Master_Sheet liées par une clé identitaire parent à la table Master_Prod, ProdID. Il y a aussi deux autres tables pour stocker l'historique, History_Prod et History_Sheet. Il y a d'autres tables qui étendent Master_Prod, mais je limite cela à deux tables à des fins d'explication.

Comme cela a été écrit en Access, la subroutine pour gérer ce fichier est parsemée de déclencheurs codés manuellement pour gérer l'historique qui ont toujours été une douleur constante à gérer, une raison pour laquelle je suis heureux que cela soit transféré vers 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 de créer un objet modélisant la feuille de calcul, d'y analyser les données et d'utiliser LINQ pour effectuer des vérifications côté client avant d'envoyer les données au serveur... En gros, je dois comparer les données de la feuille à un enregistrement correspondant (à moins qu'il n'y en ait pas, auquel cas c'est nouveau). Si l'un des champs a été modifié, je veux envoyer la mise à jour.

À l'origine, j'espérais mettre cette procédure dans une sorte d'assembly CLR qui accepte une liste IEnumerable puisque j'aurai déjà la feuille de calcul sous cette forme, mais j'ai récemment appris que cela sera associé à un serveur de base de données plutôt important qui me préoccupe beaucoup en termes de ralentissement.

Vaut-il la peine de mettre en place une procédure stockée CLR pour cela ? 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 en fonction des objets passés, alors je pourrais retirer beaucoup de règles métier de l'application au détriment des performances potentielles de la base de données.

En gros, je veux retirer la vérification des mises à jour du client et la mettre sur la base de données afin que le système de données gère si oui ou non la table doit être mise à jour pour que le déclencheur d'historique puisse être déclenché.

Des idées sur une meilleure façon de mettre en œuvre cela dans la même direction ?

Answer 1

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

SSIS est beaucoup mieux adapté à ce type de tâches que d'écrire quelque chose à partir de zéro, peu importe à quel point linq est amusant. Les packages SSIS sont plus faciles à déboguer, à maintenir et à refactoriser que certaines dll avec des sources oubliées. De plus, vous ne pourrez pas égaler les améliorations que SSIS apporte à la gestion de ses tampons pour un flux de données.

Answer 2

Initialement, j'espérais mettre cette procédure dans une sorte d'assembly CLR qui accepte une liste IEnumerable puisque j'aurai déjà la feuille de calcul dans cette forme, mais j'ai récemment appris que cela va être associé à un serveur de base de données plutôt important sur lequel je suis très préoccupé par des ralentissements.

Cela ne fonctionne pas. Toute entrée dans une procédure CLR écrite en C# DOIT encore suivre la syntaxe SQL normale. La seule chose qui peut changer est la configuration interne. Toute communication avec le client doit se faire en SQL. Ce qui signifie des exécutions / appels de méthodes. Pas de moyen de passer directement un énumérable d'objets.

Answer 3

Mon plan est/était de créer un objet qui modélise la feuille de calcul, de parser les données en lui et d'utiliser LINQ pour effectuer certaines vérifications côté client avant d'envoyer les données au serveur... En gros, j'ai besoin de comparer les données de la feuille à un enregistrement correspondant (sauf s'il n'en existe aucun, alors il s'agit de nouvelles données). Si l'un des champs a été modifié, je veux envoyer la mise à jour.

Vous devez probablement choisir une "centralité" pour votre approche - c'est-à-dire centrée sur les données ou centrée sur l'objet.

Je modèlerais probablement d'abord les données de manière appropriée. C'est parce que 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) survivront souvent aux outils/ applications client. Je commencerais probablement à essayer de modéliser de manière normale et de réfléchir aux déclencheurs pour maintenir une vérification/historique comme vous le mentionnez pendant cette période également.

Je penserais généralement ensuite aux données entrant (pas un modèle objet ou une entité, vraiment). Je me concentre alors sur le format et la sémantique des entrées et je vois s'il y a un désaccord dans mon modèle de données - peut-être qu'il y avait des hypothèses erronées dans mon modèle de données. Oui, je ne pense pas à créer un modèle objet qui valide le tableur même si les tableurs sont des sources d'entrée notoirement capricieuses. Comme Remus, j'utiliserais simplement SSIS pour l'importer - peut-être dans une table de staging et ensuite une validation supplémentaire avant de l'appliquer aux tables de production avec du T-SQL.

Ensuite, je penserais à un outil client basé sur un modèle objet basé sur mon bon modèle de données solides.

Alternativement, l'approche objet signifierait modéliser la feuille de calcul, mais aussi un modèle objet qui doit être persisté dans la base de données - et peut-être que vous avez maintenant deux modèles objets (feuille de calcul et domaine métier complet) et modèle de base de données (persistance du stockage), si le modèle objet du tableur n'est pas aussi complet que le modèle objet du domaine métier du système.

Je peux penser à un exemple où j'avais un modèle objet externe à usage unique de ce genre. Il lisait un "fichier maître" qui était un fichier de mise en page décrivant un fichier d'entrée. Ce modèle objet permettait au programme de construire des packages SSIS (et des scripts BCP et SQL) pour importer/exporter/ou faire d'autres opérations sur ces fichiers. En effet, c'était un modèle 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 parent et enfant, etc., mais simplement une représentation interne à des fins internes - il ne correspondait pas nécessairement à une entité de "domaine".