Meilleure approche pour traiter le problème des données SQL

Question

J'ai un problème de quantité de données qui nécessite beaucoup de manipulation de données et de massage et je mets cela en place pour voir si quelqu'un a une idée sur la façon de l'aborder.

Dans la forme la plus simple. J'ai beaucoup de tables qui peuvent être jointes ensemble pour me donner une liste de prix pour les dentistes et combien chaque charge pour une procédure. Nous avons donc plusieurs tables qui ressemblent à ceci.

Dentist | Procedure1 | Procedure2 | Procedure3 | .........| Procedure? 
John | 500  | 342  | 434  | .........| 843 
Dave | 343  | 434  | 322  | NULLs....| 
Mary | 500  | 342  | 434  | .........| 843 
Linda | 500  | 342  | Null  | .........| 843 

Les dentistes peuvent avoir un nombre différent de procédures et des prix différents pour chaque procédure. Mais il y a beaucoup de dentistes qui ont le même nombre de procédures et les mêmes taux qui vont avec. En interne, nous créons un identifiant unique pour chacune de ces listes de frais. Comme John serait 001, Dave serait 002, mais Mary serait 001 et Linda serait 003 Ce n'est pas si mal si je dois faire face à ces données une seule fois, mais ces listes de frais est en fichiers plats (csvs) que j'ai essentiellement à DTS jusqu'à un serveur SQL pour travailler avec. et ils viennent sur des bases mensuelles. Le prix pourrait changer de mois en mois pour chaque dentiste qui les mettrait alors dans un ID unique différent en interne. Quelqu'un peut-il nous éclairer sur la meilleure façon d'aborder ce problème de sorte qu'il soit plus efficace de traiter tous les mois sans avoir à manipuler des tonnes de données?

1. Quelle est la meilleure approche pour trouver les doublons des listes de frais?
2. Comment puis-je suivre la mise à jour de la liste des honoraires d'un dentiste, au cas où ils changeraient leurs tarifs le mois prochain? si Mary décide de facturer des frais différents pour la procédure 2, elle aura une identité unique différente en interne. Comment puis-je suivre cela sur une base mensuelle sans avoir à tout effacer et réinsérer?
3. Il ya quelques millions de listes de frais que je travaille avec et certaines ont des règles standard qui sont basées sur les codes postaux et certains sont juste des listes de frais uniques, quelle est l'approche ici?
4. Je peux écrire une sorte de programme .net ad-hoc pour travailler avec mais il y a beaucoup de données et travailler directement dans le serveur SQL serait plus facile pour moi.

toute aide serait super, merci les gars.

Answer 1

Vous devez probablement UNPIVOT les données pour normaliser - de sorte que vous vous retrouvez avec:

Doctor: DoctorID, DoctorDetails... 
FeeSchedule: DoctorID, ScheduleID, EffectiveDate, OtherDetailAtThisLevel... 
FeeScheduleDetail: ScheduleID, ProcedureCode, Fee, OtherDetailAtThisLevel... 

Lorsque les données proviennent pour un médecin, il est pivotée, un nouveau calendrier est créé et le détail les lignes sont créées à partir des données non pivotées. SSIS a un composant unpivot qui est très bien - vous devez d'abord charger l'horaire puis le détail. Si le format varie considérablement, vous pouvez avoir besoin d'une source de données personnalisée ou simplement éviter SSIS.

Ce système garderait trace des nouveaux horaires pour les médecins. Si le calendrier est identique pour un médecin, vous pouvez simplement ne pas l'insérer.

Si cette logique est étendue, vous pouvez charger les données dans des tables de transfert (SSIS ou autre) et faire tout cela en SQL (T-SQL dispose également d'un opérateur UNPIVOT). Cela peut avoir des avantages en ce que le code est tout en un seul endroit et peut faire toutes ses opérations dans des ensembles.

En ce qui concerne les codes postaux, si le médecin n'a pas de frais, sont-ils comme les frais habituels et habituels? Cela pourrait simplement être déterminé à partir du code postal de la rangée de docteur. Dans ce cas, vous avez quelques options. Vous pouvez superposer le barème des frais de médecin sur un barème de frais de code:

ZipCodeSchedule: ZipScheduleID, ZipCode, EffectiveDate 
ZipCodeScheduleDetail: ZipScheduleID, ProcedureCode, Fee 

Ou vous pouvez sauvegarder au feeschedule régulière (éventuellement avec une sorte de drapeau qu'il a été réglé par défaut sur la DUC).