Dokumentowanie gigantycznej sieci powiązanych procedur przechowywanych w bazie danych MS SQL: Jakie narzędzie lub format?

Mam nadzieję, że jest to pytanie z krótszą odpowiedzią niż „Przeczytaj 1000 stronicową książkę”, ale jeśli taka jest prawdziwa sytuacja, to mnie uderz.

Nie jestem prawdziwym DBA, jestem programistą, który zdaje sobie sprawę, że potrzebujemy DBA, a jednak sklep, w którym pracuję, nie ma DBA. Jednak nasz projekt bazy danych MS SQL, w tym kilka podstawowych procedur przechowywanych, jest ogromnym bałaganem. Procedury przechowywane są powolne, podejrzewamy, że mają one błędy, ale nie wiemy nawet, jak powinny działać, więc nie wiemy, jak je naprawić.

Na początek zdecydowałem, że udokumentujemy, jak to wszystko ma działać, a następnie zaczniemy testy jednostkowe i zbudowanie zestawu testów jednostkowych, które pomogą udowodnić, że przechowywane procedury rzeczywiście działają. Logika, którą wykonują, jest kluczową częścią naszej aplikacji, można powiedzieć, że jest „klejnotem koronnym” głównego produktu naszej firmy, a sposób jej działania jest całkowicie nieudokumentowany.

Szukam konkretnej dokumentacji technicznej, której profesjonalny DBA mógłby oczekiwać, że mógłby istnieć, lub mógłby napisać siebie, gdyby musieli zrozumieć gigantyczną sieć przechowywanych procedur, które się nawzajem wywołują.

1. Jaki jest zwykły format dokumentowania dużej procedury składowanej? Opis oczekiwanych wartości dla każdego parametru In (tj. „Warunków wstępnych”, „warunków dodatkowych”, tj. Parametrów boolowskich, które zmieniają się po włączeniu lub wyłączeniu itp.)

2. Jak zwykle to dokumentuje? Tylko komentarze SQL? Zewnętrzne oprzyrządowanie specyficzne dla celu? Zewnętrzna „dokumentacja”? Nie mamy żadnych narzędzi SQL innych niż MS SQL Management studio, ale zastanawiamy się, czy istnieje narzędzie, które poprawiłoby zrozumienie, dokumentowanie i testowanie naszego środowiska. Może to lepszy sposób, by zadać moje pytanie; Jakiego narzędzia potrzebuję, aby rozwiązać nasz bałagan?

Naszym celem jest:

A. Skorzystaj z generowanej przez nas dokumentacji lub dowolnych narzędzi, które dodamy do naszego środowiska, aby zrozumieć, w jaki sposób procedury powinny działać, abyśmy mogli następnie utworzyć test jednostkowy dla procedur przechowywanych.

B. Pokaż programistom aplikacji klienckich, jak prawidłowo wywoływać każdą z tych złożonych procedur przechowywanych.

C. Test jednostkowy naszych procedur przechowywanych.

Najważniejsze w dokumentacji jest to, że ma ona dla ciebie sens. Nie ma naprawdę standardowego sposobu na zrobienie tego.

Jeśli masz wiele procedur przechowywanych, które łączą się ze sobą, zaczynając od diagramu Visio z jednym obiektem dla każdej procedury, następnie łącz je między nimi, abyś mógł śledzić, jak przebiegają poszczególne procedury, to prawdopodobnie całkiem dobry początek.

RedGate SQL Dependency Tracker narzędzie może być pomocne. Może graficznie pokazać, które obiekty bazy danych (SP / widoki / tabele) są od siebie zależne. Użyłem go podczas pracy z niektórymi tabelami, których nie znałem, aby określić kolejność wyłączania ograniczeń.

Uruchomiłem go również dla całej bazy danych dla zabawy i to był sposób TMI. Jeśli jesteś w stanie skoncentrować się na określonych obszarach DB, które nie są od siebie uzależnione od szaleństwa, może to być pomocne. Drzewo zależności ma opcje wizualnego organizowania się przy użyciu różnych algorytmów, co samo w sobie sprawia, że ​​eval się opłaca.

Rysunek kalkowy. Inną opcją jest zapisywanie wierszy dziennika na początku i na końcu krytycznych procedur przechowywanych. Każdy wiersz może zawierać datę, „poziom szczegółowości”, najlepiej „kontekst”, „podkontekst”, nazwę proc. i liczba wierszy. Prawdopodobnie będzie to bałagan (pomyśl dziennik zdarzeń systemu Windows), ale być może przydatne w niektórych sekcjach. Jeśli do wykonania dziennika jest używany SP, to można go łatwo włączyć / wyłączyć bez większego obciążenia (ymmv).

Na marginesie: kiedyś załadowałem drukarkę fajnym papierem 11 x 17, znalazłem ładną drobną czcionkę i logiczne wcięcie podsumowujące złożony przepływ danych / SP na ~ 5 stronach jakiegoś pseudo-SQL. Jestem prawie pewien, że skończyłem na tym tylko kilka razy i nikt nie odważyłby się do niego podejść, ponieważ nie było to standardowe i trudno jest zaufać czemuś, co nie jest zintegrowane i może przestać być aktualne. Proces dokumentacji wymusił jednak znajomość kodu!

Paul White zmienił mnie w bezpłatne narzędzie Atlantis Schema Surf od Atlantis Interactive, które może ci pomóc.