Prawie wszystkie aplikacje wymagają przechowywania danych. Wymagania te mogą się zmieniać, począwszy od zupełnie podstawowych jak przechowywanie niewielkiej liczby opcji startowych, aż do olbrzymich i złożonych baz danych jak np. bazy przechowujące informacje o wykształceniu wszystkich obywateli danego kraju. Równie ważne jest to, że wymagania stawiane pojemności nośników danych także mogą się zmieniać, począwszy od potrzeby przechowania prostych plików tekstowych o ustalonej długości aż do dużych obiektów binarnych.
Bardzo waży jest wybór rozwiązania odpowiedniego dla danego problemu. Nie ma przecież sensu używanie skomplikowanego serwera bazy danych do przechowywania obrazu wyświetlanego jako „tapeta” na ekranie monitora. Podobnie nie ma też sensu próba przechowywania w jednym pliku tekstowym wszystkich danych potrzebnych w dużym domu maklerskim do śledzenia kursów akcji.
Właściwy wybór zależy zarówno od objętości, jak i od rodzaju danych. Jeżeli dane zawierają dużą liczbę „pojedynczych obiektów” (traktując słowo „obiekt” w jego ogólnym sensie), które muszą być przechowane, to odpowiednim rozwiązaniem może być baza w postaci prostego lub indeksowanego pliku tekstowego. Jeśli dane mają strukturę hierarchiczną, wówczas lepsza może być struktura drzewiasta używana np. w serwerze LDDP (z serwerem LDAP spotkamy się w dalszych częściach książki).
Jeżeli dane zawierają obiekty kilku różnych rodzajów, powiązanych przez swoje właściwości, dobrym rozwiązaniem będzie prawdopodobnie relacyjna baza danych. Bazy tego typu są bardzo elastyczne i umożliwiają przechowywanie większości struktur danych, łącznie ze strukturami drzewiastymi, jeśli jest to konieczne.
Korzystając z systemu operacyjnego Linux, znajdujemy się w szczęśliwym położeniu, bowiem dysponujemy wieloma sposobami zarządzania swoimi danymi i możemy wybrać rozwiązanie spełniające nasze wymagania. W najprostszym przypadku możemy użyć prostych plików tekstowych albo stosując niskopoziomowe API, albo wykorzystując ułatwiający dostęp do danych interfejs gnome_config, jeśli aplikacja będzie aplikacją Gnome. Jeżeli nasze wymagania nie są skomplikowane, a potrzebny jest szybki dostęp do danych, to możemy rozważyć użycie funkcji ndbm. Umożliwiają one przechowywanie prawie dowolnych danych i zapewniają bardzo wydajny dostęp za pomocą indeksów. Funkcje te zostały opisane w książce Beginning Linux Programming wydanej przez wydawnictwo Wrox Press. Rozwiązania tego rodzaju nie są jednak właściwe przy bardziej skomplikowanych potrzebach i nie będziemy się nimi dalej zajmować.
Na dalszych miejscach skali mamy do wyboru trzy główne bazy: mSQL, MySQL i PostgreSQL, które omówimy w dalszych częściach książki. Można także rozważać użycie bazy InterBase, która formalnie jest produktem komercyjnym, ale w czasie pisania tej książki była dostępna dla systemu Linux bezpłatnie łącznie z pełnym kodem źródłowym. Jeśli nasze wymagania są ostrzejsze, to możemy rozważyć użycie jednej z zaadaptowanych dla systemu Linux komercyjnych baz danych, takich jak DB2, Sybase lub Oracle. Na szczęście niewielu użytkowników ma aż tak wygórowane wymagania i większość z nich może zupełnie pomyślnie posługiwać się otwartym oprogramowaniem w rodzaju MySQL lub PostgreSQL, które całkowicie spełnia ich potrzeby.
Zanim przejdziemy do omawiania bardziej technicznych zagadnień, omówimy skrótowo trzy najpopularniejsze otwarte rozwiązania wykorzystujące SQL i dostępne w systemie Linux. Zastanowimy się także nad tym, które z nich będzie najlepiej spełniać nasze wymagania stawiane bazie danych. Podczas pisania tej książki dostępne były kody źródłowe dla wszystkich trzech baz danych, a MySQL i PostgreSQL były ponadto wolne od opłat licencyjnych. Możliwe, że w przyszłości ograniczenia licencyjne zostaną złagodzone lub zaostrzone, albo też nowsze wersje kodów źródłowych nie będą swobodnie rozpowszechniane, należy więc sprawdzić aktualny stan licencji na stronach macierzystych tych produktów.
David Hughes, pracownik naukowy Bond University w Australii, pracował nad oprogramowaniem do zarządzania siecią o nazwie Minerva, które wymagało użycia bazy danych. Chciał on użyć standardowego języka SQL, ale w owym czasie jedyną „wolną” bazą danych był Postgres, w którym zastosowano własny język zapytań o nazwie PostQUEL. David napisał interfejs programowy przetwarzający podstawowe zapytania SQL na PostQUEL i przekazujący je do serwera Postgres. Nazwano go MiniSQL lub mSQL. Wkrótce okazało się, że użycie serwera Postgres i tłumaczenie zapytań było bardziej skomplikowane, niż się tego spodziewano i Hughes ulepszył mSQL w taki sposób, aby nie korzystać ze wspomagania serwera Postgres. Taki samodzielnie działający mSQL jest obecnie również dostępny i można go znaleźć pod adresem http://www.hughes.com/au/.
Baza MySQL powstała w podobny sposób jak mSQL. Firma TcX opracowywała aplikację wykorzystującą WWW i bazę danych i stwierdziła, że najlepszym rozwiązaniem będzie użycie SQL. Postanowiono wykorzystać API zbudowane na podstawie mSQL i tak powstał produkt o nazwie MySQL. Po pewnym czasie API dla MySQL i mSQL zaczęły się różnicować w miarę rozwoju MySQL, ale nadal podobieństwa są na tyle duże, że przenoszenie kodu z mSQL do MySQL jest dosyć łatwe. MySQL można znaleźć pod adresem http://www.MySQL.com/.
PostgreSQL wywodzi się z pakietu Ingres (bazy danych opracowanej na Uniwersytecie Kalifornijskim w Berkeley). Podczas pisania książki Ingres był nadal dostępny w ofercie handlowej firmy Computer Associates. W Berkeley, wkrótce po bazie Ingres, opracowano także inną bazę o nazwie Postgres, która była wykorzystywana do eksperymentów z relacjami między obiektami. Początkowo Postgres zupełnie nie korzystał z SQL, ale około roku 1995. Jolly Chen i Andrew Yu dodali obsługę SQL i wydali nową wersję o nazwie Postgres95.
Po koniec roku 1996. prace rozwojowe przejął zespół związany z ruchem wolnego oprogramowania i produkt ponownie zmienił nazwę, tym razem na PostgreSQL, pod którą jest aktywnie rozwijany do dzisiaj. Ponieważ PostgreSQL nie jest objęty żadnymi restrykcjami komercyjnymi, zatem może być swobodnie rozpowszechniany. Dzięki temu jest dostępny w wielu dystrybucjach Linuksa. Można go pobrać z sieci z adresu http://www.postgresql.org/.
Mamy więc trzy bazy danych przeznaczone do przeciętnych zastosowań, a każda z nich ma dostępny kod źródłowy — co więc należy wybrać do naszego projektu? Odpowiedź brzmi jak zawsze: zależy to od wielu czynników. Nie ma prostej odpowiedzi. W czasie pisania książki najłatwiej było dokonać wyboru między mSQL i MySQL. Baza MySQL lepiej obsługuje standard SQL i jej licencja jest nieco bardziej otwarta, a więc można ją faworyzować. Być może, podczas czytania tych słów sytuacja się już zmieniła i baza mSQL odebrała pierwszeństwo MySQL, ponieważ obydwie były aktywnie rozwijane.
Wybór między MySQL (lub być może mSQL) a PostgreSQL zależy już bardziej od naszych potrzeb. Jeżeli potrzebna jest niewielka baza danych z szybko działającymi zapytaniami, przeznaczona do zastosowań wewnątrz firmy lub użytku osobistego i nie jesteśmy zbyt mocno zainteresowani używaniem transakcji (które wyjaśnimy później) lub bardzo zaawansowanymi aspektami SQL, to najprawdopodobniej najlepszym wyborem będzie MySQL. W rzeczywistości jest ona szeroko stosowana na wielu serwerach WWW, w których obsługa transakcji jest o wiele mniej ważna niż szybkość pobierania danych. Wynika to stąd, że serwery WWW wymagają tylko odczytu danych przekazywanych do klienta, zaś potrzeba modyfikacji danych występuje tam bardzo rzadko.
Jeśli jednak chcemy rozpowszechniać naszą aplikację z bazą danych i jesteśmy zainteresowani użyciem mechanizmów transakcyjnych, to PostgreeSQL będzie prawdopodobnie jedyną możliwością wyboru. Aby dokonać wyboru między tymi krańcowo różniącymi się bazami, należy samodzielnie przestudiować strony macierzyste obydwu produktów i ocenić je według swoich potrzeb. Obydwie bazy są na pewno bardzo dobre.
W pozostałych częściach tego rozdziału i w następnych rozdziałach skoncentrujemy się na bazie PostgreSQL z następujących powodów:
Copyright (c) 1994-8 Regents of the University of California
Permission to use, copy, modify, and distribute this software and its documentation for any purpose, without fee, and without a written agreement is hereby granted, provided that the above copyright notice and this paragraph and the following two paragraphs appear in all copies.
(Pozostałe części zawierają standardowe zastrzeżenia).
Nie mamy zamiaru rozwodzić się tutaj szeroko o instalacji bazy PostgreSQL, ponieważ baza ta została prawdopodobnie już zainstalowana lub jest dostępna w danej dystrybucji Linuksa. Jeżeli tak nie jest, to należy pobrać ją ze strony o adresie http://www.postgresql.org i zainstalować we własnym zakresie. Dostępne są zarówno wersja źródłowa, jak i pakiety binarne. Polecamy instalację pakietów binarnych, ponieważ jest to łatwiejsze i szybsze niż samodzielna kompilacja.
Po pierwszym uruchomieniu serwera PostgreSQL pojawia się tylko jedna baza danych o nazwie template1 i z tą bazą należy się połączyć. Domyślnie dostęp do serwera ma tylko jeden użytkownik o nazwie postgres, mający uprawnienia administratora bazy danych (jest on tworzony podczas instalacji pakietu).
Po zainstalowaniu PostgreSQL należy się upewnić, czy proces serwera bazy działa i czy serwer został zainicjowany. Aby zainicjować bazę, należy zalogować się jako root i utworzyć katalog /usr/local/pgsql/data. Właścicielem tego katalogu powinien być użytkownik postgres:
# chown postgres /usr/local/pgsl/data
Następnie należy zmienić tożsamość na użytkownika postgres:
# su - postgres
i zainicjować PostgreSQL w następujący sposób:
# /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
Teraz należy sprawdzić, czy działa proces postmaster (taką nazwę nosi proces serwera bazy PostgreSQL):
# ps axw
Jeśli proces postmaster został uruchomiony, wówczas w zależności od wyboru instalacji możemy zobaczyć komunikat zbliżony do poniższego:
474 p1 S 0:00 /usr/local/pgsql/bin/postmaster -D/usr/local/pgsql/data
Jeżeli proces postmaster nie działa, to należy go uruchomić za pomocą polecenia:
# /usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data
Oczywiście, jeżeli zmienna $PATH zawiera katalog /usr/local/pgsql/bin lub jego równoważnik, to nie trzeba używać pełnej ścieżki w poleceniu i wystarczy tylko napisać:
# postmaster -D /usr/local/pgsql/data
Warto więc zmodyfikować zmienną $PATH, aby zaoszczędzić czas w przyszłości.
Zazwyczaj dystrybucja jest przygotowywana w taki sposób, że przy pierwszym uruchomieniu serwera wywoływane jest automatycznie polecenie initdb inicjujące bazę PostgreSQL. Można sprawdzić, czy w pliku konfiguracyjnym systemu po instalacji PostgreSQL automatycznie jest wywoływany demon serwera PostgreSQL.
W niektórych starszych dystrybucjach (np. w Red Hat 6.0) funkcja initdb nie była wywoływana automatycznie i nie była tworzona pusta wzorcowa baza danych. Ręczna inicjacja bazy jest opisana na macierzystej stronie WWW firmy Red Hat oraz w książce Professional Linux Deployment wydanej przez Wrox.
Po upewnieniu się, że proces postmaster działa, możemy połączyć się z serwerem. Łączenie polega na połączeniu się z bazą danych. Podobnie jak w innych „prawdziwych” bazach, jeden proces serwera PostgreSQL może obsługiwać wiele różnych baz.
W pakiecie PostgreSQL istnieje wygodne narzędzie o nazwie psql wspomagające dostęp do bazy danych z wiersza poleceń. Wykorzystamy je do eksperymentów z bazą, zanim użyjemy do tego celu języka programowania.
Aby sprawdzić, czy serwer działa poprawnie, najpierw trzeba stać się administratorem bazy danych. W tym celu, po zalogowaniu jako root, należy użyć polecenia:
Teraz możemy połączyć się z serwerem:
$ psql template1
Przy odrobinie szczęścia powinniśmy otrzymać sekwencję komunikatów podobną do poniższej:
Welcome to psql, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with internal slash commands
\g or terminate with semicolon to execute query
\q to quit
template1=#
Udało się! Połączyliśmy się z działającym serwerem PostgreSQL. Oczywiście, podczas czytania tego fragmentu książki będą już istniały prawdopodobnie nowsze wersje, lecz ogólna zasada podłączenia pozostanie zapewne nie zmieniona.
Teraz należy zakończyć sesję psql, ponieważ normalnie nie powinno się korzystać z serwera jak administrator bazy, podobnie jak nie powinno się korzystać z konta root przy normalnej pracy w systemie Linux. Aby zakończyć sesję psql, należy użyć polecenia:
Template1=# \q
Pojawi się wówczas znak zachęty wiersza poleceń. Do poleceń rozpoczynających się od znaku „\” powrócimy za chwilę.
Ponieważ serwer działa poprawnie, musimy utworzyć użytkownika tego serwera. Zazwyczaj najwygodniej jest wykorzystać tę samą nazwę, która jest używana przy logowaniu do systemu. Do tworzenia użytkownika bazy PostgreSQL służy polecenie createuser. Na początku musimy wykonać tę czynność jako użytkownik postgres, ponieważ jedynie to konto tworzone przy inicjacji serwera ma uprawnienia administratora serwera. Jest to także jedyny użytkownik rozpoznawany początkowo przez serwer PostgreSQL.
$ createuser rick
Shall the new user be allowed to create databases? (y/n) y
Shall the new user be allowed to create more new users? (y/n) n
CREATE USER
$
Do usuwania użytkownika służy polecenie dropuser.
Możemy zatem zalogować się we własnym imieniu i uruchomić polecenie psql template1, podłączając się do serwera. Zauważmy, że zezwoliliśmy nowemu użytkownikowi na tworzenie nowych baz danych. Domyślnie tylko użytkownik o uprawnieniach administratora może tworzyć nowe bazy.
Zazwyczaj wygodnie jest zezwolić użytkownikom na tworzenie własnych baz danych. Stają się oni w ten sposób ich administratorami i nie wymagają pomocy od administratora serwera PostgreSQL (nie wymaga to także zmiany tożsamości przy logowaniu). Dzięki takiemu podejściu minimalizowana jest również konieczność używania konta administratora postgres.
Ponieważ mamy już odpowiednie uprawnienia jako zwykły użytkownik systemu Linux, możemy uruchomić psql, podłączyć się do bazy template1 i utworzyć własną bazę danych. Bazy są zazwyczaj tworzone i usuwane z poziomu poleceń psql za pomocą normalnych mechanizmów SQL i następujących poleceń:
template1=# CREATE DATABASE <Dbname>;
template1=# DROP DATABASE <...
jholo