SQL Server - окрема база даних для звітів?

На нашому SQL Server у нас є база даних для кожного з наших веб-додатків. Для звітів ми використовуємо служби звітування, а всі дані звіту (включаючи параметри звіту) надходять із збережених процедур.

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

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

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

Це може вплинути на це:

• Чи впливає на звіт більше ніж одне підключення до бази даних на швидкість звіту?
• Чи перешкоджає використання звітів про звітність в окремій базі даних від даних, щоб ми не могли використовувати індексовані види?
• Чи вважаєте ви, що легше / важче адмініструвати звіти в окремій базі даних?

Будь ласка, дайте мені знати, що ви думаєте.

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

1. Повторіть базу даних на іншому сервері та перемістіть на неї звітні відростки. Звіти запускаються з реплікаційного сервера. Це найменше зусиль і може повторно використовувати наявні звіти та збережені процедури.
2. Створіть Склад даних, який консолідує дані з ваших виробничих систем та перетворить їх у форму, яка дружніша для звітування . Якщо у вас є багато спеціальної статистичної звітності, яка могла б бути зроблена сприйнятливо з огляду на "закриття бізнесу вчора", сховище даних може бути кращим підходом.

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

Я також вважаю цю статтю корисною.

Я б рекомендував не переносити збережені процедури в іншу базу даних з кількох причин. З точки зору розвитку, ви повинні відтворювати дві бази даних кожного разу, коли ви хочете внести зміни. Як наслідок, тепер ви дізнаєтеся, як синхронізувати схему з бази даних "data" та збережені процедури з другої з виробничими версіями. Що стосується відновлення після аварій та резервного копіювання / відновлення, то тепер вам доведеться зайнятися відновленням 2 баз даних, щоб розпочати роботу системи.

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

Я рекомендую вам використовувати дві бази даних.

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

Крім того, оскільки база даних звітів передусім для пошуку, ви можете налаштувати тут індекси для кращої продуктивності. (Жива база даних матиме вставки, на які певні індекси негативно впливатимуть)

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