Contexte
J'écris de nombreux rapports volumineux et je gère généralement une grande base de données de dossiers de santé (écriture de SP, fonctions, travaux, etc.). Le schéma d'origine et le logiciel qui l'utilise proviennent d'un fournisseur différent, donc je ne peux pas y changer grand-chose structurellement. Il existe de nombreux enregistrements qui nécessitent un suivi tels que les laboratoires, les procédures, les vaccins, etc. et ils sont dispersés sur des dizaines de tableaux, dont beaucoup sont gonflés et mal indexés (j'ai pu résoudre ce problème quelque peu).
Le problème
Le problème est que, parce que nous avons peu de contrôle sur la base de données et qu'elle peut changer à partir d'une mise à jour ou d'un correctif donné, cela rend la rédaction et la maintenance de ces rapports difficiles et fastidieuses, en particulier en cas de chevauchement important. Tout ce qu'il faut, c'est un patch et je suis coincé à réécrire de grandes parties d'une douzaine de rapports. De plus, les requêtes deviennent rapidement obscurcies et lentes à mesure que les jointures, les sélections imbriquées et les applications s'empilent.
Ma "solution"
Mon plan consistait à écrire tous ces enregistrements dans une table «fourre-tout» et à écrire des déclencheurs sur les tables d'origine pour conserver les enregistrements dans cette table agrégée. Bien sûr, je devrais m'assurer que mes déclencheurs étaient intacts après les mises à jour, mais cela serait beaucoup plus facile du point de vue de la maintenabilité et du simple référencement des données.
Le tableau serait mince et long, ne stockant que les données requises, quelque chose comme ceci:
CREATE TABLE dbo.HCM_Event_Log (
id INT IDENTITY,
type_id INT NULL,
orig_id VARCHAR(36) NULL,
patient_id UNIQUEIDENTIFIER NOT NULL,
visit_id UNIQUEIDENTIFIER NULL,
lookup_id VARCHAR(50) NULL,
status VARCHAR(15) NULL,
ordered_datetime DATETIME NULL,
completed_datetime DATETIME NULL,
CONSTRAINT PK_HCM_Event_Log PRIMARY KEY CLUSTERED (id)
)
Ensuite, j'aurais diverses tables relationnelles pour des choses comme les groupements type_id et item.
Je commence à deviner cette idée, car plusieurs de ces tableaux sont écrits dans une certaine mesure, les SP et les rapports que j'écrirais feraient également référence aux données. Je crains donc que cette table ne devienne un cauchemar de verrouillage et de performances avec autant d'E / S.
Ma question
Est-ce une mauvaise ou une bonne idée? Je me rends compte que chaque situation est différente dans SQL Server (2008 r2 Standard Edition BTW), et la règle «parfois», mais je suis vraiment à la recherche de conseils généraux.
J'ai commencé à envisager d'utiliser un courtier de services, mais je n'effectuerais que de simples mises à jour / insertions ( voir l'alternative à la réponse acceptée ). Dans de nombreux cas, les données doivent être en temps réel, donc l'utilisation d'une base de données de sauvegarde ne fonctionnerait pas vraiment. Les performances sont déjà quelque peu un problème pour nous, mais la plupart d'entre elles sont liées au matériel et seront bientôt résolues.