tło
Piszę wiele dużych raportów i ogólnie prowadzę dużą dokumentację medyczną DB (piszę SP, funkcje, zadania itp.). Oryginalny schemat i oprogramowanie, które go używa, pochodzi od innego dostawcy, więc nie mogę wiele zmienić strukturalnie. Istnieje wiele zapisów, które wymagają śledzenia, takich jak laboratoria, procedury, szczepionki itp. I są one rozrzucone po dziesiątkach tabel, z których wiele jest rozdętych i źle indeksowanych (udało mi się to nieco naprawić).
Problem
Problem polega na tym, że ponieważ mamy niewielką kontrolę nad bazą danych, a ponieważ może ona zmieniać się z dowolnej aktualizacji lub poprawki, sprawia, że pisanie i obsługa tych raportów jest trudna i żmudna - szczególnie, gdy nakładają się na siebie duże nakłady. Wystarczy jedna łatka i utknąłem przepisując duże części tuzina raportów. Ponadto zapytania szybko stają się zaciemnione i powolne w miarę łączenia, zagnieżdżania zaznaczeń i nakładania stosów.
Moje „rozwiązanie”
Mój plan polegał na zapisaniu wszystkich tych rekordów w jednej tabeli „catch-all” i zapisaniu wyzwalaczy na oryginalnych tabelach w celu utrzymania rekordów w tej tabeli zbiorczej. Oczywiście musiałbym upewnić się, że moje wyzwalacze były nienaruszone po aktualizacji, ale byłoby to o wiele łatwiejsze z punktu widzenia łatwości konserwacji i po prostu odwoływania się do danych.
Tabela byłaby cienka i długa, przechowująca tylko wymagane dane, mniej więcej tak:
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)
)Potem miałbym różne tabele relacyjne dla takich rzeczy jak ID_typu i grupowanie elementów.
Zaczynam zastanawiać się nad tym pomysłem, ponieważ kilka z tych tabel jest napisanych dość często, SP i raporty, które piszę, również często odnoszą się do danych. Dlatego obawiam się, że ta tabela stanie się koszmarem blokowania rekordów i wydajności przy tak dużej liczbie operacji we / wy.
Moje pytanie
Czy to zły czy dobry pomysł? Zdaję sobie sprawę, że każda sytuacja jest inna w SQL Server (2008 R2 Standard Edition BTW) i reguła „czasami”, ale tak naprawdę szukam tylko ogólnych porad.
Zacząłem rozważać skorzystanie z brokera usług, ale wykonuję tylko proste aktualizacje / wstawki ( zobacz alternatywę dla zaakceptowanej odpowiedzi ). Dane w wielu przypadkach muszą być przesyłane w czasie rzeczywistym, więc użycie kopii zapasowej bazy danych naprawdę nie działałoby. Wydajność już stanowi dla nas pewien problem, ale większość z nich dotyczy sprzętu, który wkrótce zostanie rozwiązany.