Документування величезної павутини взаємозалежних збережених процедур у базі даних MS SQL: Який інструмент чи формат?

Я сподіваюся, що це питання з коротшою відповіддю, ніж «Прочитайте книгу на 1000 сторінок», але тоді, якщо це реальна ситуація, то вразить мене цим.

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

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

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

1. Який звичайний формат документування великої збереженої процедури? Опис очікуваних значень для кожного параметра Параметри (тобто "передумови", "пост-умови", тобто для булевих параметрів, що змінюється, коли ви вмикаєте або вимикаєте і т.д.?)

2. Як зазвичай це документується? Лише коментарі SQL? Зовнішній інструмент, специфічний для цілі? Зовнішня "документація"? У нас немає інших інструментів SQL, окрім студії MS SQL Management, але нам цікаво, чи є інструмент, який би покращив розуміння, документування та тестування нашого середовища. Можливо, це кращий спосіб задати моє запитання; Який інструмент мені потрібен, щоб вирішити наш безлад?

Наша мета - вміти:

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

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

C. Випробування блоку наших збережених процедур.

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

Якщо у вас є багато збережених процедур, які всі підключаються один до одного, починаючи з діаграми Visio з одним об'єктом для кожної процедури, то зв’язки між ними, щоб ви могли відслідковувати, як переходять справи від процедури до процедури, мабуть, досить вдалий початок.

Інструмент відстеження залежності SQL RedGate може бути корисним. Він може графічно показати, які об’єкти бази даних (SP / представлення / таблиці) залежать один від одного. Я використовував це під час роботи з деякими незнайомими таблицями, щоб визначити порядок відключення обмежень.

Я також запустив його по всій базі даних просто для розваги, і це було так TMI. Якщо ви зможете зосередити його на конкретних областях БД, які не є божевільними взаємозалежними, це може бути корисним. Дерево залежностей має можливість візуально впорядкувати себе за допомогою різних алгоритмів, і лише це робить оцінку непотрібною.

Простеження. Інший варіант - написати рядки журналу на початку та в кінці критично збережених процедур. Кожен рядок може містити дату, "рівень деталізації", "найкращий здогад", "контекст", "підтекст", назву проц. і ряди. Можливо, це буде безлад (думаю, що журнал подій Windows), але, можливо, корисний у деяких розділах. Якщо SP використовується для фактичного введення журналу, то його можна легко включати / вимикати без особливого додаткового навантаження (ymmv).

Бічна примітка, я одного разу завантажив принтер із прохолодною папером розміром 11 х 17, знайшов приємний крихітний шрифт та певне логічне відступ для узагальнення складного потоку даних / SP на ~ 5 сторінок псевдо-SQL. Я впевнений, що я лише кілька разів звертався до нього, і ніхто більше не наважувався наблизитися до нього, оскільки там це було не стандартно і важко довіряти чомусь не інтегрованому, і він може застаріти. Хоча процес документування змусив ознайомитися з кодом!

Пол Уайт перевів мене на безкоштовний інструмент Atlantis Schema Surf від Atlantis Interactive, який може вам допомогти.