Wygoda i prostota

Te same narzędzia wsadowe można wykorzystać wraz z programem, który na podstawie odbieranych z telefonu predefiniowanych wiadomości SMS dokonuje stosownych zmian w bazie danych. Cały skrypt zajmuje ok. 40 wierszy, wiadomości z telefonu są czytane za pomocą programu Nokii. Całość działa prosto i skutecznie. Analogicznie działający program napisany w takim języku, jak C++ czy Visual Basic, byłby co najmniej 10 razy obszerniejszy.

Korzystanie z narzędzi skryptowych wymaga nieco innego podejścia do problemu niż to, które reprezentują programiści. Gdy programista bazodanowy dostaje zadanie sprzęgnięcia programu do taryfikacji rozmów telefonicznych z firmowym intranetem pracującym z bazą MySQL albo Oracle, zazwyczaj będzie próbował napisać program, który połączy się przez ODBC z dwiema bazami i pobierając dane z jednej, zapisze je do drugiej.

To "eleganckie rozwiązanie" ma jednak słabe punkty. Po pierwsze, ODBC czasami jest kłopotliwe, a czasami po prostu niewydajne. Ponadto są programy, które używają własnego silnika bazodanowego, niezgodnego z ODBC. W takim przypadku programista ma bardzo utrudnione zadanie. Tymczasem doświadczony administrator przygotuje eksport do pliku tekstowego (taką opcję ma większość programów), który potem wczyta za pomocą narzędzi typu SQL*Loader czy bcp. Jeśli nie może użyć loadera, to przerobi cały plik za pomocą skryptu awk do postaci "INSERT INTO TABELA VALUES...", a następnie przekaże do interfejsu, który wykona stosowną liczbę takich prostych poleceń.

Wbrew pozorom posłużenie się skryptem jest proste i działa dostatecznie szybko. Co istotne, dzięki usłudze cron każde zadanie skryptowe można łatwo automatyzować. Ponadto efekt pracy skryptu można zapisać do dowolnej bazy, która posiada pracujący z wiersza poleceń program umożliwiający wykonywanie transakcji (mysql, isql, sqlplus). W ten sam sposób można wykonać eksport, gdy dla bazy danych brak sterowników ODBC.

Skrypty na bazie

Daje się zauważyć tendencja wykorzystania istniejącej od lat technologii skryptowej tak, by czerpiąc z jej możliwości, dać administratorom narzędzie funkcjonalnie bogate, a jednocześnie łatwe w obsłudze. Pewna część programów w systemie Linux, pracując z graficznym interfejsem użytkownika, jest de facto nakładką, która przygotowuje stosowny skrypt, prowadząc użytkownika "za rękę".

Dzięki takiemu podejściu zaawansowany użytkownik będzie mógł z czasem nauczyć się korzystania z języka skryptowego. W ten sposób Oracle zachęca do wykorzystywania języka PL/SQL w swoim graficznym narzędziu DBA Studio - na większości ekranów znajduje się przycisk pokazujący kod PL/SQL odpowiadający wprowadzanym właśnie zmianom. Po pewnym czasie pracy z PL/SQL, drobne zmiany szybciej będzie można wykonać za pomocą programu SQL*Plus.

W dziedzinie baz danych skrypty w języku takim jak PL/SQL mają się bardzo dobrze i nieprędko będzie można całkowicie zastąpić je czymkolwiek innym. Przyczyn jest wiele, choćby to, że już są, działają dobrze, są powszechnie wykorzystywane i łatwiejsze w analizie niż gotowe aplikacje. Ponadto można je przystosować do różnych potrzeb - czego nie można powiedzieć do końca o gotowych, specjalizowanych programach.

Obecne bazy danych nie wymagają już tak wielu czynności administracyjnych jak niegdyś, ale administrator nadal często korzysta ze skryptów, np. do odświeżania statystyk albo do tworzenia zapytań ad hoc. Sporo takich skryptów administratorzy "przynoszą ze sobą", ale zwykle potrafią stworzyć je na poczekaniu. Wymaganie od administratorów, by dokumentowali wszystkie skrypty przeznaczone do pojedynczego działania (single task tool), jest chyba nie na miejscu. Co innego, gdy skrypt ten ma pracować dłużej - wtedy komentarze umieszczone w nim samym są bardzo ważne.