Неудобна ли практика сбора данных из разных таблиц в одну?

Фон

Я пишу много больших отчетов и обычно поддерживаю большую базу данных о работоспособности (пишут СП, функции, задания и т. д.). Исходная схема и программное обеспечение, использующее ее, принадлежат другому вендору, поэтому я не могу изменить ее структурно. Есть много записей, которые требуют отслеживания, таких как лаборатории, процедуры, вакцины и т. Д., И они разбросаны по десяткам таблиц, многие из которых раздуты и плохо проиндексированы (я смог это исправить).

Проблема

Проблема заключается в том, что, поскольку мы мало контролируем БД, и поскольку он может меняться от любого заданного обновления или патча, это затрудняет и утомительно записывает и поддерживает эти отчеты, особенно когда есть много перекрытий. Все, что требуется, это один патч, и я застрял, переписывая большие части из дюжины отчетов. Кроме того, запросы быстро становятся запутанными и медленными, поскольку соединения, вложенные выбирает и применяют нагромождение.

Мое «решение»

Мой план состоял в том, чтобы записать все эти записи в одну таблицу «catch-all» и написать триггеры в исходных таблицах, чтобы вести записи в этой совокупной таблице. Конечно, мне нужно было бы обеспечить, чтобы мои триггеры были неповрежденными после обновлений, но это было бы намного проще с точки зрения ремонтопригодности и просто ссылкой на данные.

Таблица будет тонкой и длинной, сохраняя только требуемые данные, примерно так:

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 и item.

Я начинаю вторгаться в эту идею, поскольку некоторые из этих таблиц написаны довольно много, SP и отчеты, которые я буду писать, будут также ссылаться на данные. Поэтому я обеспокоен тем, что эта таблица станет кошмаром записи и производительности с таким количеством операций ввода-вывода.

Мой вопрос

Плохо или хорошая идея? Я понимаю, что каждая ситуация различна в SQL Server (2008 r2 Standard Edition BTW) и правило «иногда», но я действительно просто ищу общий совет.

Я начал рассматривать использование сервис-брокера, но я выполнял только простые обновления /вставки ( См. альтернативу принятому ответу ). Данные во многих случаях должны быть в реальном времени, поэтому использование резервной базы данных не будет работать. Производительность для нас уже немного важна, но большая часть из них связана с оборудованием, которая скоро будет решена.

12 голосов | спросил jreed121 14 AM00000020000005231 2015, 02:51:52

1 ответ


3

Я работал с очень похожей ситуацией, подобной этой в прошлом в 24x7 производственной компании и, наконец, решил использовать транзакционную репликацию. Возможно, чтобы настроить DDL реплицируется таким образом, что вы можете выталкивать все изменения патчей подписчику. Очевидно, что есть все за и против, и вам нужно взвесить их, чтобы определить, что вы можете поддержать против того, что лучше всего подходит для компании.

С положительной стороны:

  1. «В режиме реального времени» ограничивается только производительностью сети и транзакции для абонента. По моему опыту с умеренно высокой системой TPS мы были реплицированы до менее чем 10 секунд от данных «в реальном времени».
  2. Разделение рабочих нагрузок. В настоящее время вы выполняете смешанную рабочую нагрузку на одном сервере. Если вы можете отделить эти две проблемы, то вы можете получить преимущества производительности на обеих системах, удалив одну рабочую нагрузку из уравнения.
  3. Control. Вы сможете сделать индексирование /статистику /модификации обслуживания в соответствии с вашей рабочей нагрузкой.

Есть минусы:

  1. Стоимость. Другая лицензия и другое оборудование (виртуальное или иное).
  2. Репликация. Он отлично работает, как только он правильно настроен, но это может быть проблемой для достижения этой цели.
  3. Обслуживание. Если вы производите какие-либо вредные изменения в структурах (например, отбрасываете индекс), они возвращаются при применении моментального снимка (после изменения публикации или изменения статей).
ответил swasheck 18 AM00000070000005831 2015, 07:32:58

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132