[nierusz]

Hej Mirki, potrzebuję narzędzie do debugowania błędów merytorycznych w procedurach SQL. Normalnie jak jest jeden błąd, w jednej procedurze, to wystarcza Management Studio. Jednak gdy w grę wchodzi 6 procedur, po ponad 2k linii kodu każda i do tego na wzajem siebie wywołujących to wymiękam.

Bardziej mi zależy na czymś opisowym, co pozwoli kontrolować wprowadzane przez mnie zmiany, prowadzić mini dokumentacje i zapisywanie efektów tych zmian, niż typowe narzędzie do SQLa.

#programowanie #sql

[Arogancky]

@nierusz: może warto przejść na DBT?
u mnie migrujemy sie ze sqlservera na data warehouse i co możemy to idzie do DBT. W miarę ok jest jeśli chodzi o testy i inne pierdoły. A chyba też obsługuje normalne silniki bazodanowe

[Arogancky]

@nierusz: tak w sumie patrze w stare procedury dla SQL servera to ludzie po prostu pisali komentarze na samej górze co tam pododawali w danym dniu i czemu. No i + git i jakoś to chyba szło

[nierusz]

@Arogancky: niektóre procedury mają po 20 lat i jest tam masa komentarzy od developerów. Lista zmian na początku (czasem ponad 300 zmian) plus szczegóły w kodzie. I ja muszę znaleźć która zmiana wprowadziła bałagan kilka procedur dalej. O zmianie środowiska nie ma mowy, bo to potężny ERP.

[Arogancky]

@nierusz: ło #!$%@? xD to u mnie takich cudów nie ma chyba, ale nie grzebałem za głęboko żeby sie nie wystraszyć ;)

[user-agent-switcher]

@nierusz: Jetbrains DataGrip.
Luzno rzucam propozycje. Nic innego nie przychodzi mi do glowy do wydajnej pracy z #!$%@? SQL.

[janek_]

po ponad 2k linii kodu każda

@nierusz: to jest sygnał, że te procedury należy zrefaktorować. (albo, że pracujesz w miejscu, w którym nikt nie dbał o jakość kodu)

Podejrzewam, że taka procedura zajmuje się jednocześnie kilkoma różnymi rzeczami, być może nawet ze sobą niezwiązanymi. Należy ją podzielić na mniejsze procedury (idealnie - realizujące pojedyncze zadania), które łatwiej będzie Ci utrzymywać, testować i zmieniać w razie potrzeby.

---
Plus oczywiście używaj

[nierusz]

@janek_: Te procedury muszą mieć tyle linii. Akurat te 6 procedur, po 2k linii każda, odpowiadają za liczenie ekwiwalentu za urlop z uwzględnieniem wszystkich możliwości jakie dopuszcza polskie prawo, jednocześnie pozwalając na przeliczanie z zachowaniem zmian prawnych z ostatnich 20 lat, tak na wypadek gdyby trzeba było coś po kontroli skorygować. Cały ERP ma logikę napisaną w SQLu i to są setki tysięcy linii procedur, funkcji i innych dziwadeł.

I teraz

[janek_]

@nierusz: no właśnie, można to spróbować tak rozpisać, żeby każdy oddzielny przypadek był obsługiwany oddzielną procedurą, którą jesteś w stanie przetestować

i dopisać jeszcze jedną procedurę, której zadaniem będzie konsolidacja wyników zwracanych przez te procedury :)

[nierusz]

@janek_: Dzięki za ten tutorial. Od prawie 20 używałem SQL Management Studio, zamiast jak człowiek skorzystać z Visual Studio (którego używam prawie równie długo).

Nie można tego zrobić tak jak piszesz, aby dla każdego przypadku była inna procedura. Parametrów biorących udział w wyliczeniach będzie cos koło 25. Do tego te parametry zmieniały się w czasie. Dane do ekwiwalentu w zależności od przypadku brane są nawet z kilku lat wstecz (np. kobieta

[janek_]

@nierusz : a co do testowania:
robisz sobie jakąś testową tabelkę z kilkunastoma zmyślonymi pracownikami i ich atrybutami (czyli wszystkimi parametrami, które są brane pod uwagę przez tę procedurę przy wyliczaniu ekwiwalentu) oraz wpisaną na sztywno wyliczoną przez eksperta poprawną kwotę ekwiwalentu

a potem tylko porównujesz wyniki zwrócone przez procedurę z tym wynikiem, którego się spodziewasz