Wszelkie prawa zastrzeżone. Rozpowszechnianie arty kułu bez zgody Software Wy dawnictwo Sp. z o.o. zabronione.

Transkrypt

1 2 / Wszelkie prawa zastrzeżone. Rozpowszechnianie arty kułu bez zgody Software Wy dawnictwo Sp. z o.o. zabronione. Softw a r e W y da w n ict w o Sp. z o.o., u l. Lew a r tow skieg o 6, W a r sza w a, POLSKA. Kon ta kt : Da r iu sz Pa w łow ski (dpa w low ski@ph psolm a g.or g )

2 Początki, czyli Interbase za darmo Anatol Ogórek Programista PHP najczęściej wybiera MySQL lub PostgreSQL wychodząc z założenia, że produkt najpopularniejszy oznacza najlepszy. Ten warunek nie zawsze jest jednak spełniony. Od 2000 roku bardzo intensywnie rozwijany jest projekt. Efektem prac jest darmowa, w pełni relacyjna i profesjonalna baza danych, wprost idealna dla webdeweloperów. W SIECI 1. oficjalna strona a 2. informacje na temat Interbase/ 3. strona dla użytkowników IB/FB 4. de/ strona z narzędziami dla IB/FB (po niemiecku) 5. strona dla początkujących użytkowników FB 6. rge.net/ interfejs webowy do zarządzania FB/IB NA CD Na dołączonym do pisma CD znajdują się wszystkie omawiane w artykule skrypty oraz program instalacyjny a. Zalet spółki PHP + SQL nie sposób nie docenić. Co ciekawe, wielu webmasterów utożsamia SQL-a z bazą danych MySQL sądząc, że jest to jedyne słuszne rozwiązanie. Niektórzy wykorzystują też coraz popularniejszego SQLite'a lub linuksowego PostgreSQL-a. To jednak nie koniec dobrych rozwiązań. Mało tego, istnieją systemy lepsze, a jednym z nich jest. Nazwa wielu osobom skojarzy się (po części słusznie) z odchudzoną przeglądarką internetową Mozilla, którą nieświadomie ochrzczono w ten sposób. Spowodowało to spore zamieszanie i wiele dyskusji, ponieważ nazwa ta była już wcześniej zajęta przez darmową bazę danych, która mimo wielu zalet ciągle jest niestety mało znana. 25 lipca 2000 roku Borland opublikował kod źródłowy swojej, do dzisiaj bardzo popularnej bazy Interbase na licencji IPL (InterBase Public License v.1.0). Wtedy na jego podstawie został zapoczątkowany projekt SQL, który ma na celu dalsze rozwijanie bardzo już solidnego narzędzia Borlanda. stał się bazą danych oferowaną na licencji Open Source, a co za tym idzie, zupełnie darmową i do dzisiejszego dnia intensywnie rozwijaną. Co należy wiedzieć? Czytelnikowi przyda się ogólna wiedza na temat relacyjnych baz danych. Powinien też znać podstawy PHP. Co obiecujemy? Z artykułu czytelnik dowie się, jak zbudować aplikację bazodanową w oparciu o a, z uwzględnieniem takich cech jak transakcyjność, wyzwalacze czy blokady na poziomie wierszy. Powiemy też, dlaczego a w przeciwieństwie do MySQL-a można uważać za w pełni relacyjną bazę danych. 44

3 Początki Dostępny jest na wielu różnych platformach, począwszy od Linuksa, poprzez szereg innych systemów uniksowych i Microsoft Windows, a na Mac OS X kończąc. Przyjrzyjmy się bliżej jego możliwościom. Potęga ognistego ptaka Niewątpliwie za jedną z większych zalet a można uznać jego łatwość obsługi. Instalacja pod Windows sprowadza się do kilku kliknięć myszką, natomiast w systemach uniksowych wystarczy uruchomić odpowiedni skrypt instalacyjny. Baza potrzebuje bardzo niewielu zasobów systemowych, zarówno jeśli chodzi o miejsce na dysku jak i pamięć operacyjną. Wynika to stąd, że silnik Interbase projektowany był w czasach, gdy komputery nie miały jeszcze tak dużej mocy obliczeniowej jak obecnie. Nie oznacza to, że baza jest prymitywna - wręcz przeciwnie, funkcjonalnością dorównuje wielu komercyjnym i drogim odpowiednikom. Pliki bazy danych mogą być rozmieszczone w wielu różnych miejscach na dysku i nic nie stoi na przeszkodzie, aby przechowywać je na osobnych partycjach. Jest to niewątpliwą zaletą, jeśli spodziewamy się, że nasza baza może w przyszłości osiągnąć duży rozmiar. Kolejną cechą a jest niemal pełna zgodność ze standardami SQL: zaimplementowano w niej większość cech SQL-89, SQL-92 oraz część właściwości SQL-99. System posiada pełną obsługę złączeń warunkowych i bezwarunkowych (ang. inner join, left join, right join, outer join), unie (ang. unions) i perspektywy (ang. views). Dla użytkowników MySQL-a nowością będzie możliwość korzystania z podzapytań (ang. subqueries). Dodatkowo wsparcie dla pól wyliczanych (ang. calculated fields), procedur składowanych (ang. stored procedures), wyzwalaczy (ang. triggers), wyzwalaczy na perspektywach, więzów (ang. constraints) czy też lokalizacji sprawia, że bazę można uznać za w pełni profesjonalną. Generatory Każda baza danych posiada swój mechanizm nadawania unikalnych identyfikatorów. Przykładowo w MySQL możemy korzystać z pól typu autoincrement, a w Oracle z sekwencji. W zie wykorzystuje się generatory. Generator nie jest ściśle powiązany z żadną kolumną, ani nawet z żadną tabelą. Może się zdarzyć, że jeden generator będzie obsługiwał wszystkie tabele naszej bazy. Zwykle jednak przyjmuje się, że istnieje osobny generator dla każdej tabeli, która posiada klucz główny (ang. primary key). Aby stworzyć generator, wystarczy wykonać polecenie: CREATE GENERATOR nazwa_generatora; Następnie, aby nadawanie unikalnych numerów odbywało się automatycznie, można na tabelę założyć wyzwalacz: :SET TERM!! ; CREATE TRIGGER SET_UNIQUE_ FOR OUR_TABLE BEFORE INSERT AS BEGIN IF (NEW. IS NULL) THEN NEW. = GEN_(OUR_TABLE_GENERATOR, 1); END!! SET TERM ;!! W tym wypadku przed wstawieniem wiersza do tabeli, jeśli pole ma wartość NULL nadawana jest mu kolejna wartość generatora. Nie jest jednak konieczne używanie wyzwalaczy. Wartość generatora można również pobrać i wstawić do bazy ręcznie za pomocą funkcji: GEN_(nazwa_generatora, skok). Bardzo ważną cechą generatorów jest to, że nie są transakcyjne. Jeśli rozpoczniemy transakcję, pobierzemy kolejną wartość z generatora, a następnie anulujemy transakcję, generator nie cofnie się do poprzedniej wartości. Wbrew pozorom jest to olbrzymia zaleta, ponieważ daje nam stuprocentową pewność, że otrzymamy unikalne. Dla webdeweloperów świetnie nadaje się do tworzenia dynamicznych serwisów WWW. Ciężko podać przypadek, w którym nie sprostałby naszym wymaganiom. Jeśli potrzebujemy bazy prostej w administracji, wieloplatformowej, mającej niewielkie wymagania sprzętowe, a do tego darmowej, wybór może być tylko jeden. Istnieje oczywiście Postgre- SQL, lecz uruchomienie go na systemach innych niż Linux jest dość trudne. PostgreSQL ma też zdecydowanie większe wymagania, jeśli chodzi o zasoby systemowe oraz przestrzeń na dysku, a jego konfiguracja i administracja jest znacznie bardziej skomplikowana. Warto dodać, że tempo rozwoju a jest zawrotne, a kolejne wersje przynoszą coraz większą funkcjonalność i wydajność systemu. Praktyka Zalety a można mnożyć bardzo długo. Przejdźmy jednak do konkretów. Załóżmy, że tworzymy serwis wymagający wysokiej niezawodności, bezpieczeństwa oraz kontroli integralności danych. Potrzebujemy więc bazy z doskonałą obsługą transakcyjności. Transakcja to zbiór operacji, których wykonanie musi zakończyć się sukcesem. W przypadku niepowodzenia którejkolwiek z nich wszystkie powinny być anulowane. Transakcje opisuje zasada AC Atomicity, Consistency, Isolation, and Durability: Atomicity transakcja może być wykonana tylko w całości albo wcale, Consistency stan bazy danych zawsze przedstawia stan przed lub po transakcji. Zapytania do systemu w czasie wykonywania transakcji muszą pokazywać stan bazy przed transakcją, Isolation transakcja zachodzi niezależnie od innych wykonywanych operacji, w tym od innych transakcji, Durability w przypadku awarii całego systemu bazodanowego transakcje pozostają kompletne. W naszym projekcie MySQL niestety się nie sprawdzi, ponieważ transakcje w tej bazie są dopiero w powijakach. Jeśli dodatkowo system ma być dostępny na różnych platformach systemowych, nie mamy zbyt wielkiego wyboru. Pokażemy teraz, jak w praktyce wygląda wykorzystanie a z poziomu PHP. Spróbujemy wykorzystać transakcyjność za pomocą funkcji wbudowanych 45

4 Początki Listing 1. Tworzymy tabelę INVOICE DROP TABLE INVOICE; CREATE TABLE INVOICE( INTEGER NOT NULL PRIMARY KEY, NUMBER varchar(30) default '', DOC_DATE date, SALE_DATE date, CONTRACTOR varchar(250) default '', NETTO NUMERIC(15,2) default 0, VAT NUMERIC(15,2) default 0, GROSS_SUM NUMERIC(15,2) default 0 ); DROP GENERATOR INVOICE_GEN; CREATE GENERATOR INVOICE_GEN; w PHP oraz zastosować wyzwalacze i procedury składowane. Zacznijmy więc od podstaw, czyli od instalacji. Instalacja Wersja dla Microsoft Windows rozpowszechniana jest w postaci standardowego instalatora. Jedyna opcja, którą warto zaznaczyć, to copy client library to <system> directory, co spowoduje, że biblioteka FBCLIENT.DLL zostanie skopiowana do katalogu systemowego. Na koniec należy jeszcze zadecydować, czy ma być uruchamiany jako usługa (Win XP, Win 2000) czy jako aplikacja (Win 9x). Po kilku minutach mamy zainstalowaną i gotową do użycia bazę danych. W przypadku Linuksa po pobraniu i rozpakowaniu pakietu należy z poziomu użytkownika root uruchomić skrypt install.sh, który cały proces instalacji wykona automatycznie. Nasza baza zostanie zainstalowana w katalogu /opt/firebird/. Wszystkie niezbędne narzędzia administracyjne znajdują się w katalogu instalacyjnym, w podkatalogu bin/. Będziemy jeszcze poproszeni o podanie standardowego hasła masterkey dla domyślnego użytkownika SYSDBA (administratora bazy danych). Oczywiście można korzystać z ustawień domyślnych, co pozbawia nas wszelkich dodatkowych czynności administracyjnych, ale nie jest to bezpieczne. Warto zmienić domyślne hasło oraz założyć nowego użytkownika. W tym celu należy skorzystać z polecenia gsec z podkatalogu bin/:./gsec -user SYSDBA -pass masterkey Listing 2. Tworzymy tabelę POSITIONS oraz generator DROP TABLE POSITIONS; CREATE TABLE POSITIONS( id INTEGER NOT NULL PRIMARY KEY, _INVOICE INTEGER, ITEM VARCHAR(20) default '', QUANTITY NUMERIC(15,3) default 0, NETTO NUMERIC(15,2) default 0, VAT_RATE NUMERIC(5,2) default 0); DROP GENERATOR POSITIONS_GEN; CREATE GENERATOR POSITIONS_GEN; SET TERM!!; create trigger POSITIONS_GEN_ for POSITIONS BEFORE INSERT POSITION 0 AS BEGIN NEW.id = GEN_(POSITIONS_GEN,1); END!! SET TERM ;!! Następnie możemy zmienić hasło administratora: GSEC>modify SYSDBA S -pw nowe_hasło oraz dodać nowego użytkownika foo z hasłem bar: GSEC>add foo -pw bar GSEC>quit Po tych czynnościach możemy utworzyć nową bazę danych, której właścicielem będzie użytkownik foo. Można to zrobić z poziomu konsoli isql:./isql SQL>CREATE DATABASE 'invoice.gdb's USER 'foo' PASSWORD 'bar'; Na dysku została utworzona baza danych plik invoice.gdb. pozwala dodatkowo na skopiowanie tego pliku w dowolne miejsce na dysku stanowi to jego olbrzymią zaletę. Wystarczy, że w ścieżce do bazy podczas połączenia wpiszemy: localhost:/sciezka/do/pliku/s invoice.gdb i baza zostanie poprawnie otwarta (zakładając oczywiście, że nadane są prawa do odczytu/zapisu pliku). W ten sposób możemy utworzyć kilka różnych baz danych i rozmieścić je na osobnych partycjach. Daje to nam dużą elastyczność i pewność, że w razie braku miejsca na jednej z partycji, możemy umieścić plik z bazą na nowo dodanym dysku zmieniając jedynie ścieżkę dostępu. W dalszej części artykułu zakładamy, że użytkownik korzysta z systemu Linux (w przypadku systemu Windows zmiany będą niewielkie w większości wypadków wystarczy jedynie zmodyfikować ścieżki dostępu) oraz że plik invoice.gdb znajduje się w katalogu /opt/firebird. Przykład z życia Załóżmy, że piszemy skrypt do wystawiania faktur VAT. Tworzymy więc pliki invoice.sql (Listing 1) oraz positions.sql (Listing 2) i wykonujemy dodając do bazy nowe tabele: /opt/firebird/bin/isql -u foo S -p bar /opt/firebird/ invoices.gdb<invoice.sql /opt/firebird/bin/isql -u foo S -p bar /opt/firebird/s invoices.gdb<positions.sql Zakładamy, że użytkownik wprowadził już dane. Pora wykorzystać PHP i połączyć się z em spójrzmy zatem na Listing 3. Do nawiązania połączenia służy funkcja ibase _ connect(). Teraz musimy zapisać dane do tabel. Aby mieć pewność, że dane zostały zapisane poprawnie, musimy w tym miejscu rozpocząć transakcję: $tr = ibase_trans($dbh);s Po tej czynności możemy przejść do właściwych operacji, czyli zapisu danych. Zakładamy, że dane faktury znajdują się w tablicy asocjacyjnej, której pola mają takie same nazwy jak pola tabeli w bazie danych. Na początku musimy zapisać ogólne dane dotyczące faktury do tabeli INVOICE. W tym celu należy najpierw pobrać wartość generatora przypisanego do tej tabeli za pomocą zapytania: select GEN_(INVOICE_GEN, 1)S FROM RDB$DATABASE Teraz możemy wstawić do bazy dane faktury. Należy wspomnieć, że znaną praktyką jest wstawianie wartości do 46

5 Początki tabeli przed pobraniem wygenerowanego identyfikatora przy pomocy funkcji MAX(nazwa _ pola). W przypadku aplikacji WWW postępowanie takie jest bardzo niebezpieczne, ponieważ może się okazać, że otrzymaliśmy identyfikator rekordu, który w międzyczasie wstawił ktoś inny. Wtedy zapisywane w kolejnym kroku pozycje dopisalibyśmy do zupełnie innej faktury. Bezpieczeństwo tego typu operacji w znacznej mierze zależy od stosowanego przez bazę danych poziomu izolacji (ang. isolation level). Dla a domyślnie jest to poziom snapshot (transakcja ma dostęp do wszystkich tabel, lecz nie do zmian wprowadzonych i zatwierdzonych przez inne, rozpoczęte później transakcje), w którym moglibyśmy skorzystać z funkcji MAX() do pobrania identyfikatora ostatnio dodanej pozycji, lecz jeśli przełączylibyśmy poziom izolacji np. na read commited (transakcja ma dostęp do wszystkich tabel i zmian wprowadzonych oraz zatwierdzonych przez inne transakcje) mogłoby się okazać, że nasz program w niektórych przypadkach nie działa poprawnie. Mamy zatem pobrane wcześniej faktury możemy zapisać do bazy wszystkie pozycje tablicy POSITIONS z tym identyfikatorem jako kluczem obcym. Jeśli w trakcie wystąpi błąd zapisu którejkolwiek pozycji, powinniśmy wycofać wszystkie operacje (wraz z zapisaniem danych ogólnych) oraz wyświetlić odpowiedni komunikat błędu. Wyzwalacze Wyzwalacz (ang. trigger) to specjalna procedura, uruchamiana automatycznie podczas zajścia operacji na bazie danych. W zie można tworzyć wyzwalacze uruchamiane przed lub po wstawianiu (INSERT), modyfikacji (UPDATE) lub skasowaniu (DELETE) rekordu. Wyzwalacze nie służą jedynie go generowania unikalnych identyfikatorów. Można je wykorzystać do wielu różnych celów na przykład do obsługi pól automatycznie wyliczanych, jednak głównym ich zadaniem jest zapewnienie spójności danych w bazie. Na przykład, po skasowaniu faktury, powinny również zostać usunięte wszystkie jej pozycje. W tym celu możemy stworzyć odpowiedni wyzwalacz, który pobierze identyfikator usuniętego rekordu i skasuje wszelkie pozycje z takim kluczem obcym Listing 4. Po dodaniu takiego wyzwalacza Listing 3. Łączymy się z em i wstawiamy dane do bazy <?php $host = 'localhost:/opt/firebird/invoice.gdb'; $username = 'foo'; $password ='bar'; $dbh = ibase_connect($host, $username, $password); if (!$dbh) die ("error connecting to database"); $tr = ibase_trans( $dbh); $invoice = array("number"=>"2/04/2004", "DOC_DATE"=>" ","SALE_DATE"=>" ", "CONTRACTOR"=>"Jan Kowalski Sp. z o.o", "NETTO"=>"100","VAT"=>"22","GROSS_SUM"=>"122"); $poz= array( array( "ITEM"=>"Drukarka", "QUANTITY"=>"2", "NETTO"=>"400","VAT_RATE"=>"0.22"), array("item"=>"monitor", "QUANTITY"=>"1", "NETTO"=>"1200","VAT_RATE"=>"0.22")); // pobieramy wartość pola id przed wstawieniem do bazy $query = 'select GEN_(INVOICE_GEN, 1) FROM RDB$DATABASE'; $sth = ibase_query($tr, $query); if (!$sth) database_error ("Błąd przy pobieraniu ", $tr); $row = ibase_fetch_row($sth); $id = $row[0]; $query = "INSERT INTO INVOICE (, NUMBER, DOC_DATE, SALE_DATE, CONTRACTOR, NETTO, VAT, GROSS_SUM) VALUES('$id', '${invoice[number]}','${invoice[doc_date]}', '${invoice[sale_date]}','${invoice[contractor]}', '${invoice[netto]}','${invoice[vat]}','${invoice[gross_sum]}')"; // wstawiamy fakturę do bazy $sth = ibase_query($tr, $query); if (!$sth) database_error ("Błąd przy wstawianiu faktury", $tr); // wstawiamy kolejno wszystkie pozycje faktury for ($a = 0; $a<count( $poz ); $a++) { $query = "INSERT INTO POSITIONS (_INVOICE, ITEM, QUANTITY, NETTO) VALUES($id,'".$poz[$a][ITEM]."','".$poz[$a][QUANTITY]."', '".$poz[$a][netto]."')"; $sth = ibase_query($tr, $query); if (!$sth) database_error ("Błąd przy wstawianu pozycji", $tr); } // wszystko poszło OK. Zatwierdzamy transakcję. ibase_commit($tr); echo ("Fakturę dodano pomyślnie"); // funkcja obsługująca błędy function database_error ($error, $transaction) { // wycofujemy transakcję ibase_rollback($transaction); }?> // i kończymy działanie skryptu komunikatem o błędzie die($error); 47

6 Początki Listing 4. Wyzwalacz, który usunie wszystkie pozycje faktury z danym kluczem obcym DROP trigger delete_invoice; SET TERM!!; create trigger delete_invoice for invoice AFTER DELETE AS BEGIN delete from positions where id_invoice=old.; END!! SET TERM ;!! działa zupełnie inaczej. Domyślnie każda transakcja widzi swoją wersję rekordu z chwili, kiedy została rozpoczęta. Zmiany wprowadzone przez inne transakcje nie są widoczne, dopóki transakcje nie zostaną zatwierdzone (commit). Najlepiej zobrazuje to poniższy przykład: Otwieramy pierwszą sesję, która modyfikuje pozycję z tabeli BOOK: Session #1: SQL> select * from book; 1 Lord of the rings Widać, że każda z sesji posiada odrębne wersje rekordów widoczne w ramach swojej transakcji. Zatwierdźmy teraz wprowadzone zmiany: Session #1: SQL> commit; Session #2: SQL> commit; SQL> select * from book; możemy wejść do konsoli isql i usunąć ręcznie jedną z wstawionych wcześniej faktur. Przekonamy się, że pozycje będą kasowane automatycznie. Procedury składowane Użytkownicy mający doświadczenie w pracy z dużymi środowiskami bazodanowymi zapewne nieraz korzystali z procedur składowanych (ang. stored procedures). Są to procedury pisane w wewnętrznym języku bazy danych, parsowane i kompilowane jednorazowo przed pierwszym wykonaniem. Zastosowanie ich znacząco odciąży naszą aplikację, przyspieszy jej działanie i zwiększy bezpieczeństwo. W zie również możemy pisać takie procedury przy użyciu języka PSQL, który, choć może mniej rozbudowany od swoich odpowiedników w ORACLE czy PostgreSQL, spełnia wymagania większości użytkowników. Dodatkowo, pozwala na tworzenie funkcji UDF (User Defined Functions). Są one pisane w zewnętrznym języku (np. C/C++ lub Delphi), a następnie kompilowane do postaci bibliotek współdzielonych (*.dll lub *.so). Biblioteki te ładowane są do bazy danych, po czym można z nich korzystać z poziomu SQL-a. Procedury składowane w połączeniu z funkcjami UDF mogą przerzucić część ciężaru czasochłonnych operacji na silnik bazy danych, a co za tym idzie dodatkowo zwiększyć wydajność aplikacji. Blokady na poziomie wierszy MySQL domyślnie oferuje blokady wyłącznie na poziomie tabel. W przypadku bardzo obciążonych serwisów metoda taka jest dalece nieefektywna. Mechanizm transakcji w zie 1 Lord of the rings SQL> update book set title = 'Harry Potter' where id = 1; SQL> select * from title; 1 Harry Potter Na poziomie tej sesji, zawartość tabeli została zmodyfikowana. Otwieramy drugą sesję, która odwołuje się do tej samej tabeli: Session #2: SQL> select * from book; 1 Harry Potter Jak widać. niezatwierdzona transakcja z sesji pierwszej nie zabroniła dostępu do danych transakcji z sesji drugiej, jednakże widoczne były nieuaktualnione (stare) dane. Innym bardzo ważnym mechanizmem blokowania dostępu do rekordów jest select for update. Ta metoda gwarantuje, że żadna inna sesja nie zmieni wybranych danych, dopóki sesja blokująca nie zakończy ich przetwarzania (czyli nie zatwierdzi transakcji). Spójrzmy na poniższy przykład: Session #1: SQL> select * from book where id = 1 for update Pseudorelacyjność kontra MySQL Klucze obce służą do tworzenia połączeń relacyjnych (relacji stąd właśnie pochodzi nazwa relacyjna baza danych) pomiędzy tabelami. W większości przypadków dopasowywane pola to: klucz podstawowy (primary key) z głównej tabeli, który dostarcza unikatowego identyfikatora, dla klucza obcego z każdego rekordu w drugiej tabeli. Weźmy bazę danych dokumentów z księgowości tabele dokumenty i kontrahenci: tabela dokumenty zawiera m. in. kolumny id _ dokumentu (klucz główny), numer, data, kontrahent, a tabela kontrahenci: kolumny id _ kontrahenta (klucz główny), nazwisko, adres, telefon, , itp. Kolumna dokumenty.kontrahent może być kluczem obcym odnoszącym się do kolumny kontrahenci.id _ kontrahenta. Unika się w ten sposób powielania tych samych danych w różnych tabelach, co m. in. ułatwia utrzymanie zgodności pomiędzy zawartością bazy danych, a stanem faktycznym. Nic nie stoi na przeszkodzie, aby taką relację stworzyć bez kluczy głównych/obcych, lecz wtedy nie będzie zachowana pełna integralność danych. Dzięki kluczom silnik bazy danych dba o to, aby do tabeli podrzędnej możliwe było wstawienie jedynie rekordów, które mają przyporządkowany wpis w tabeli głównej. Niemożliwe będzie również usunięcie rekordu z tabeli głównej, jeśli nie zostały wcześniej usunięte wszystkie przyporządkowane mu rekordy z tabeli podrzędnej. MySQL nie posiada pełnego wsparcia dla mechanizmu kluczy głównych, dlatego często bywa nazywany pseudorelacyjną bazą danych. Częściowa implementacja dostępna jest jedynie dla tabel typu InnoDB. oferuje pełne wsparcie dla kluczy obcych, wraz ze sprawdzaniem więzów integralności. 48

7 Początki with lock; 1 Lord of the rings Session #2: SQL> update book set title = 'PHP Solutions' where id = 1; (Blokada) Jak widać, w tym wypadku druga sesja nie może modyfikować nawet swojej wersji rekordu. Może tego dokonać dopiero po zatwierdzeniu transakcji w obu sesjach. Należy zaznaczyć, że takie sterowanie dostępem do rekordów równie dobrze możemy zastosować z poziomu PHP. MySQL nie oferuje tak rozbudowanego mechanizmu obsługi transakcji, nawet jeśli korzystamy z tabel typu InnoDB. Abstrakcyjny dostęp do a Wielu webmasterów przyzwyczaiło się już do korzystania z abstrakcyjnych metod dostępu do bazy danych. Nie ma w tym nic dziwnego, jako że w PHP obsługa każdej bazy danych odbywa Listing 5. Przykład połączenia z bazą przy użyciu biblioteki PEAR <?php?> require_once("pear.php"); require_once("db.php"); $dsn = array( 'phptype' => 'ibase', 'username' => 'foo', 'password' => 'bar', 'hostspec' => 'localhost', 'database' => '/opt/ firebird/invoice.gdb', ); $options = array( 'persistent' => true ); $db = DB::connect($dsn,$options); $sql = "select * from invoice"; $result = $db->query($sql); $row = $result->fetchrow(); print_r ($row); $db->disconnect(); Listing 6. Przykład połączenia z bazą przy użyciu biblioteki ADOdb <? include("adodb.inc.php"); $db = NewADOConnection('firebird'); $db->connect("localhost", "foo", "bar", "/opt/firebird/.gdb"); $result = $db->execute("select * FROM POSITONS"); if ($result === false) die("błąd"); while (!$result->eof) { for ($i=0, $max=$result->fieldcount(); $i < $max; $i++) print $result->fields[$i].' '; $result->movenext(); print "<br>"; }?> się za pomocą osobnych funkcji. Jeśli potrzebujemy przenośności kodu oraz niezależności od bazy danych, powinniśmy skorzystać z bibliotek takich jak AdoDB czy PEAR:DB. Zobaczmy, jak interfejsy te radzą one sobie z em. i PEAR:DB PEAR to zbiór bibliotek i rozszerzeń PHP będących odpowiednikiem perlowskiego CPAN, dzięki którym budowa nawet skomplikowanej aplikacji staje się o wiele prostsza. PEAR dołączany jest do każdej oficjalnej dystrybucji PHP, dzięki czemu pisany przez nas kod staje się w pełni przenośny. Jednym z komponentów tej biblioteki jest również klasa DB, która zapewnia zunifikowane API obsługi baz danych. Wśród wielu wspieranych baz jest również /Interbase. Jeśli wcześniej tworzyliśmy swoje projekty przy użyciu tej biblioteki można modyfikując kilka linijek kodu dostosować je do współpracy z em. Na Listingu 5 przedstawiliśmy przykład połączenia z bazą przy użyciu biblioteki PEAR. Wygląda ono podobnie, jak w przypadku innych baz danych. Tworzymy DSN (Data Source Name) i wypełniamy go odpowiednimi parametrami. W przypadku a (Interbase) dobrze jest przekazać DSN w postaci obiektu, a nie łańcucha. W przeciwnym wypadku mogą wystąpić problemy z połączeniem. Następnie tworzymy obiekt $options, który do prawidłowego połączenia z bazą danych musi zawierać pole: persistent => true; Do danych odwołujemy się w identyczny sposób jak w przypadku innych baz obsługiwanych przez PEAR:DB. i AdoDB Skrót ADODB oznacza Active Data Objects DataBase (Obiektowa Baza Danych). W uproszczeniu można powiedzieć, że jest odpowiednikiem PEAR:DB. Również ta biblioteka wśród szerokiej gamy obsługiwanych baz oferuje dostęp do a. Na Listingu 6 przedstawiliśmy prosty przykład połączenia z bazą danych. Jeśli ktoś korzystał już z tej biblioteki, na pewno nie będzie miał problemów z przesiadką na a. Wszystkich spragnionych dodatkowej wiedzy na temat AdoDB odsyłamy do artykułu AdoDB interfejsowa alternatywa z numeru 4/2004, gdzie bardzo dokładnie opisywaliśmy implementację aplikacji bazodanowej w oparciu o interfejs AdoDB. Podsumowanie Jak pokazaliśmy w artykule, imponuje funkcjonalnością znaną niemal jedynie z komercyjnych baz takich jak ORACLE czy SyBase. Jego licencja (IPL) pozwala na dowolne wykorzystanie programu również w projektach komercyjnych. Prostota instalacji i administracji, niewielkie wymagania sprzętowe oraz wysoka wydajność i niezawodność sprawiają, że przy rozpoczynaniu kolejnego projektu warto pomyśleć o zie jako dobrej alternatywie dla MySQL czy PostgreSQL. 49