Фон
Я пишу много больших отчетов и, как правило, веду большую базу данных о работоспособности (пишу SP, функции, задания и т. Д.). Исходная схема и программное обеспечение, которое ее использует, принадлежат другому поставщику, поэтому я не могу многое изменить в этом структурно. Есть много записей, которые требуют отслеживания, таких как лаборатории, процедуры, вакцины и т. Д., И они разбросаны по десяткам таблиц, многие из которых раздуты и плохо проиндексированы (я смог это исправить).
Проблема
Проблема заключается в том, что, поскольку у нас мало контроля над БД, и поскольку она может отличаться от любого данного обновления или исправления, это делает написание и ведение этих отчетов трудным и утомительным, особенно при большом количестве совпадений. Все, что нужно, это один патч, и я застрял, переписывая большие части десятка отчетов. Кроме того, запросы быстро становятся запутанными и медленными, поскольку объединения, вложенные выборки и применения накапливаются.
Мое "решение"
Мой план состоял в том, чтобы записать все эти записи в одну таблицу «всеохватывающего» и записать триггеры в исходные таблицы для ведения записей в этой сводной таблице. Конечно, я должен был убедиться, что мои триггеры не были повреждены после обновлений, но это было бы намного проще с точки зрения удобства сопровождения и просто ссылки на данные.
Таблица будет тонкой и длинной, хранящей только необходимые данные, что-то вроде этого:
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)
)
Тогда у меня были бы различные реляционные таблицы для таких вещей, как type_id и группировка элементов.
Я начинаю вторую догадываться об этой идее, так как некоторые из этих таблиц написаны довольно много, SP и отчеты, которые я буду писать, также будут ссылаться на данные. Поэтому я обеспокоен тем, что эта таблица станет кошмаром для блокировки записей и производительности с таким большим количеством операций ввода-вывода.
Мой вопрос
Это плохая или хорошая идея? Я понимаю, что в SQL Server (Standard r2 Standard Edition BTW) и в правилах «иногда» каждая ситуация различна, но я просто ищу общие советы.
Я начал рассматривать возможность использования сервисного брокера, но я буду выполнять только простые обновления / вставки ( см. Альтернативу принятому ответу ). Во многих случаях данные должны быть в реальном времени, поэтому использование резервной БД не будет работать. Производительность уже является для нас проблемой, но в основном это связано с аппаратным обеспечением, которое скоро будет решено.