Чи погана практика об’єднання даних з різних таблиць в одну?

Фон

Я пишу багато великих звітів для і, як правило, підтримую великі бази даних про стан здоров’я (пишуть 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 (2008 р2 Standard Edition BTW) кожна ситуація різна, і правило "інколи", але я дійсно просто шукаю загальну пораду.

Я почав розглянути можливість використання сервісного брокера, але виконую лише прості оновлення / вставки ( Дивіться альтернативу прийнятій відповіді ). Дані в багатьох випадках повинні бути в режимі реального часу, тому використання резервної бази даних насправді не спрацює. Продуктивність для нас вже є певною проблемою, але більшість із них стосується обладнання, яке буде вирішено незабаром.

Якщо я вас правильно зрозумів,

• у вас є велика стороння система,
• у вас немає великого контролю над цим,
• ви складаєте складні звіти, які читають дані безпосередньо з цієї сторонньої бази даних,
• ваші запити залежать від внутрішньої структури бази даних сторонніх розробників.

Я підійшов би до цього так:

• Створіть власну окрему базу даних, над якою я повністю контролюю.
• Налаштуйте процес синхронізації, який зчитує дані з відповідних таблиць і стовпців із сторонньої бази даних та вставляє / оновлює в мою.
• Розробіть мої складні звіти на основі стійкої структури моєї бази даних.

У цьому випадку ви можете налагодити структуру та індекси вашої бази даних, щоб покращити ефективність своїх звітів, не впливаючи на сторонні системи. Якщо оригінальна структура даних різко не зміниться, логіка ваших запитів для ваших звітів не зміниться, якщо зміниться база даних сторонніх розробників. Вам доведеться налаштувати лише процес синхронізації.

Процес синхронізації - це ефективно процес перетворення - ви перетворюєте дані з сторонніх баз даних у потрібну вам структуру. Частиною цього процесу перетворення може бути виправлення будь-яких проблем з нормалізацією, які можуть мати оригінальні сторонні бази даних. Тільки ця частина системи повинна знати і залежати від внутрішньої структури сторонньої системи. Ваші основні звіти та основні запити залежатимуть лише від вашої бази даних.

Отже, головний момент - відокремити та обмежити ту частину вашої системи, яка залежить від внутрішніх систем сторонньої системи.

оновлення

Стосовно вимог у режимі реального часу. До речі, я завжди вважав, що визначення поняття "в реальному часі" - це "гарантований час відповіді", а не "якийсь невеликий час відгуку". Це, звичайно, залежить від вашої заявки. У моїй практиці достатньо, якщо я синхронізую дві бази даних протягом хвилини після виявленої зміни. Якщо користувач бачить звіт на екрані і деякі основні зміни даних, його потрібно якось повторно запустити, щоб відобразити цю зміну. Ви можете опитати на зміни чи прослухати якусь подію / повідомлення, все ж запит звіту повинен бути виконаний ще раз, щоб відобразити останні зміни.

Ви вже маєте намір написати тригери для фіксації змін у вихідних таблицях і записати ці зміни в одну загальну таблицю. Отже, фіксуйте зміни так, як ви задумали, але запишіть їх у правильно нормалізовані таблиці, а не в одну.

Отже, це крайній випадок - перетворення сторонньої структури даних у вашу внутрішню структуру даних виконується в тригерах, які запускаються на INSERT/UPDATE/DELETEсторонні таблиці. Це може бути хитро. Код тригерів залежатиме від внутрішньої структури обох систем. Якщо конверсія нетривіальна, вона може затримати оригінал INSERT/UPDATE/DELETEдо моменту їх відмови. Якщо у вашому тригері є помилка, це може вплинути на оригінальну транзакцію до моменту їх відмови. Якщо стороння система зміниться, вона може порушити ваш тригер, що може спричинити збій транзакцій сторонньої системи.

Менш крайній випадок. Щоб зробити код ваших тригерів більш простим і менш схильним до помилок, напишіть усі захоплені зміни до деяких таблиць (ив) / аудит / розмін, встановіть прапор / надішліть повідомлення про те, що існують зміни в очікуванні та запустіть основний процес перетворення, який би йшов через ці посередницькі таблиці та здійснюють перетворення. Тут головне - це те, що потенційно важкий процес конверсії повинен відбуватися поза межами первинної транзакції.

З другого погляду це майже схоже на вашу оригінальну пропозицію у питанні. Але різниця полягає в тому, що всі таблиці захоплення зберігають дані лише тимчасово; обсяг даних невеликий - лише те, що змінилося; це не повинно бути єдиним столом; врешті-решт, дані зберігатимуться в окремих нормально нормалізованих постійних таблицях, якими ви повністю керуєте, які не залежать від сторонніх систем і які ви можете налаштувати під свої запити.

У будь-якому випадку помістіть його в стандартизований набір таблиць, щоб ви могли налаштувати етап імпорту, а не змінювати складний звіт (и) та запити. Але дані все одно повинні бути нормалізовані, що вимагатиме декількох таблиць (але з хорошими індексами).

Як уже згадували інші, не використовуйте тригери, синхронізуйте в партіях.

Не турбуйтеся про велику кількість приєднань, коли дані нормалізуються та індексуються належним чином, вони не додають суттєвих витрат або навантаження на управління.

Час денормалізації в щось на зразок сховища даних - це коли вам потрібно мати можливість робити безліч різних типів запитів на дані, які ви не можете передбачити. У нього є свої недоліки та накладні витрати, і їх слід використовувати там, де це доречно, а не як річ для переходу.

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

З позитивного боку:

1. "В режимі реального часу" обмежується лише виконанням мережевих та трансакційних операцій на абонента. На моєму досвіді з помірно високою системою TPS, ми були реплікані протягом менш ніж 10 секунд даних у режимі реального часу.
2. Розмежування навантажень. На даний момент ви працюєте зі змішаним навантаженням на одному сервері. Якщо ви можете відокремити ці два питання, то, можливо, ви зможете отримати переваги щодо обох систем, вилучивши з рівняння одне робоче навантаження
3. Контроль. Ви зможете внести зміни в індексації / статистиці / технічному обслуговуванні відповідно до завантаженості звітів.

Однак є і мінуси:

1. Вартість. Ще одна ліцензія та більше апаратного забезпечення (віртуального чи іншого).
2. Реплікація. Це прекрасно працює, коли він налаштований належним чином, але це може бути клопотом дістатися до цієї точки.
3. Технічне обслуговування. Якщо ви внесете будь-які шкідливі зміни в структури (наприклад, скиньте індекс), вони повернуться, коли знімок буде застосований (після зміни публікації або коли статті змінилися).

Мій план полягав у тому, щоб записати всі ці записи до однієї таблиці "загальноприйнятих" та записати тригери на початкові таблиці, щоб підтримувати записи в цій сукупній таблиці.

Тригери мають стільки проблем, що вам слід їх уникати:

• Помилка тригера може призвести до відмови оригінальної транзакції
• Тригери, які правильно керують багаторядковими операціями, важко записати
• Тригери можуть переплутати клієнтські програми, змінивши повернутий набір рядків (наприклад, тригер перевизначає кількість порушених рядків)
• Коли один тригер спрацьовує інший, результати важко передбачити

Кращий варіант - це завдання, яке періодично копіює дані в нову таблицю. Ваші звіти можуть працювати з копією. Завдання, яке копіює рядки, легко писати та підтримувати, і немає ризику, що це вплине на роботу сторонньої програми.