Aktualizacja i konserwacja skryptów SQL

Witam Wszystkich,

Moje zapytanie dotyczy konserwowania i aktualizacji skryptów SQL (baza nie ma znaczenia). Chodzi o następującą sytuację. Przeważnie skrypty zapisane są w postaci Stringów, dodatkowo przekazywane są do nich parametry. Wszystko jest OK do momentu, gdy aplikacja jest mała i w miarę stała w sensie struktur bazy danych. Jednak w jaki sensowny sposób w napisanych już skryptach SQL obsłużyć sytuację, w której następuje zmiana struktur kilku tabel, powstają nowe pola a dotychczasowe są usuwane. Kompilator Delphi nie wykryje tych zmian, gdyż dla niego zapytanie SQL to tylko string. Nie sprawdzi też poprawności nazw pól i tabel.
Stąd moje pytanie, w jaki sposób projektować i pisać zapytania SQL, aby można było nad nimi zapanować, w przypadku zmian struktur bazy danych ?

Ja uzywajac SVN robie tzw branch tj zamykam powiedzmy wersje 1.1 i wrzucam tam plik ze wszystkimi zmianami SQL dzieki temu wiem co i jak zmienilo sie w wersji 1.2 w stosunku do poprzedniej wersji.

Nie jestem pewien, czy dobrze zrozumiałem twoj koncept i cel ćwiczenia. Ale z tego co ja zrozumiałem - chodzi ci o zapobiegnięcie sytuacji, w której spróbujesz działać programem w starszej wersji, na bazie (strukturze), która została już zmodyfikowana skryptem.

Jeżeli tak programu dyżych korporacji jakie widziałem od środka radzą sobie na dwa sposoby.

Albo: W bazie jest odpowiednia tabelka, w której zapisane są wszystkie skrypty, które zostały zaaplikowane poprawnie do bazy (musisz rozpatrzec kwestie co sie stanie, kiedy część skryptu lub skryptów nie wykona się - nie zawsze sama transakcja załatwia sprawę), a aplikacja podczas uruchamiania sprawdza w jakiej wersji jest baza jezeli spełnia odpowiednie warunki - pozwala się uruchomić.

Albo: Aplikacja zawiera zbiór niezależnych modułów (w sensie aplikacja jest tylko ramą, do wyświetlania okienek poszczególnych modułów - nie ma znaczenia, czy moduły będą zawarte w osobnych dll-kach, czy aplikacja będzie się budowała dynamicznie na podstawie zewnętrznych plików konfiguracyjnych) - zmiana w jakimś obszarze funkcjonalnym (struktura bazy) wymusza wymianę modułu.

Tworzyłem projekty w oparciu o oba modele i generalnie wsio radno który wybierzesz - oba spełniają swoją funkcję.

Chyba, że nie o to ci chodziło.

Witam,

Dzięki za zainteresowanie tym wątkiem.

Generalnie moje pytanie dotyczy tego, w jaki sposób pisać obsługę bazy w SQL-u i Delphi, aby w przypadku zmian w bazie np. struktury jakiejś tabeli, szybko odnaleźć skrypty, które trzeba poprawić w ślad za tą zmianą.

Głównie chodzi o to, że skrypty zapisane są w postaci stringów. których kompilator nie analizuje pod względem zgodności użytych struktur tabel i typów poszczególnych pól. W związku z tym, jeżeli zmienimy typ lub nazwę jakiegoś pola, to ciągnie to za sobą konieczność "ręcznego" przeanalizowania wszystkich używanych skryptów i ich skorygowania. W przypadku większych projektów jest to czynność dość pracochłonna i błędotwórcza.

Stąd też moje pytanie. W jaki sposób pisać aplikację, aby szybko wyłapać skrypty SQL wymagające korekty?

Pozdrawiam

Pomyśl nad umieszczeniem skryptów bezpośrednio w bazie jako procedur. Czyli jak zmienia się struktura tabel i potrzebujesz zrobic insert, update, delete, select to modyfikujesz tylko odpowiednią procedurę odpowiedzialną za daną czynność i po sprawie. Dzięki temu nie trzeba modyfikować samego programu.

W książce "Praktyka programowania" wydanej 30 lat temu jest taka wskazówka, żeby przewidywać na etapie tworzenia programu, w jakich miejscach trzeba będzie później zrobić zmiany z powodu konserwacji, i opisać już na tym pierwszym etapie, co dokładnie trzeba będzie i w jakim miejscu zmienić w kodzie programu, gdy później te zmiany będą potrzebne. Nie wiem tylko czy te informacje pisze się zbiorczo jako komentarze w jednym miejscu, czy też w tych miejscach, które będą kiedyś wymagać zmian.

Dzięki za sugestie.

waf3l
Zgadzam się z Tobą, ale nie załatwi to wypełniania kontrolek w programie i wydruków.

Mariusz
To dotyczy sytuacji, której z wyprzedzeniem nie da się przewidzieć, aplikacja ma działać przez lata i na obecnym etapie trudno sobie nawet wyobrazić jakie zmiany będą wymagane w przyszłości.

Tak nie załatwi, wydaje mi się że nie ma na to złotego środka. Natomist procedury ułatwią Ci przekazywanie parametrów prze ADOQuery oraz odwoływanie się do poszczegółnych pól, korzystając z procedur kod w delphi staje się bardziej czytelny i łatwiej nad nim zapanować.

f-c-s napisał(a)

Dzięki za sugestie.
Mariusz
To dotyczy sytuacji, której z wyprzedzeniem nie da się przewidzieć, aplikacja ma działać przez lata i na obecnym etapie trudno sobie nawet wyobrazić jakie zmiany będą wymagane w przyszłości.

Jak będziesz konserwować cudzy program, to docenisz to, że autor zostawił komentarze odnośnie przyszłych konserwacji. Więc ty też dawaj takie komentarze żeby ułatwić innym. Można pisać je bardziej lub mniej szczegółowo, w zależności od potrzeby i od tego jaka jest szansa na dany rodzaj zmiany.

Konserwacja cudzego programu, bez istnienia w nim komentarzy dotyczących konserwacji, może być tak trudna że szybciej pójdzie napisanie swojego programu od nowa.

Podaję jeszcze ISBN dla książki którą wymieniłem: 83-204-0442-8