2006.11_Firebird SQL 2.0 _[Bazy Danych].pdf

Bazy

danych

Grzegorz Skoczylas

Firebird SQL 2.0

dy Jim Starkey, wieloletni pracownik Digital

Equipment Corporation , postanowił założyć

własną irmę Groton Database Systems i napisać ba-

zę danych o nowej, zaprojektowanej przez siebie ar-

chitekturze. Nowa baza nazywała się InterBase.

W 1991 roku irma Jima Starkeya została za-

kupiona przez Ashton Tate , irmę znaną wówczas

głównie jako producent bazy dBase. Niedługo po-

tem, bo w tym samym roku, irma Ashton Tate zo-

stała zakupiona przez irmę Borland. W chwili

przejęcia dostępny był serwer InterBase 3 . Posta-

nowiono go nadal rozwijać i dołączać go do wła-

snych narzędzi programistycznych. Spowodowało

to znaczne zwiększenie jego popularności. W po-

łowie 2000 roku zdecydowano się udostępnić ko-

dy źródłowe InterBase 6.0 na zasadach Open So-

urce. Na bazie tych kodów źródłowych kilka nieza-

leżnych grup programistów zaczęło rozwijać wła-

sne wersje serwera. Z czasem grupy te połączy-

ły swoje siły w najbardziej zaawansowanym pro-

jekcie.

Serwer Firebird 1.0 został udostępniony w po-

łowie 2002 roku. Był on zbudowany na bazie ko-

du serwera InterBase 6.0 , w którym autorzy wpro-

wadzili wiele korekt i poprawili wiele błędów. Na-

stępnie postanowiono przepisać cały kod serwera

z języka C na C++. Przy okazji tego przekodowy-

wania poprawiono wiele błędów, znacznie przy-

spieszono działanie serwera oraz dokonano sze-

regu usprawnień. W efekcie tych prac w 2004 ro-

ku udostępniony został Firebird 1.5 . Prace nad

rozwojem serwera trwają nadal. Właśnie udostęp-

niana jest wersja 2.0.

Listing 1. Przykład użycia tabel pochodnych

SELECT

FROM

( SELECT

RDB$RELATION_NAME, RDB$RELATION_ID

FROM

RDB$RELATIONS ) AS R (

RELATION_NAME, RELATION_ID )

sługujący to połączenie. W systemie Windows tylko

ta wersja serwera potrai w pełni wykorzystać plat-

formę wieloprocesorową.

Architektura Superserver została opracowana

w 1996 r. w InterBase 4.1 dla Windows. W tej archi-

tekturze jeden proces obsługuje wszystkie połącze-

nia. Charakteryzuje się większą wydajnością i mniej-

szym zapotrzebowaniem na pamięć, zwłaszcza

w przypadku wielu użytkowników.

W Firebird 1.5 wprowadzono trzecią formę ser-

wera: Embedded server . Jest to wersja Superservera

okrojona do pracy jednostanowiskowej – nie obsłu-

guje połączeń zdalnych.

Z punktu widzenia programisty zazwyczaj nie

ma znaczenia z którą wersją serwera program ma

współpracować.

Firebird 2.0

W nowej wersji serwera zaimplementowane zosta-

ło wiele nowych cech. Poprawiono lub rozbudowano

również szereg dotychczasowych możliwości. Zmia-

ny są bardzo obszerne. Ich opis zajmuje ponad 150

stron tekstu. W tym artykule skupię się ma wybra-

nych najważniejszych zmianach i nowościach.

Większość przykładów w listingach pochodzi

z dokumentu „ Firebird 2.0 Release Notes ” dla Fire-

bird 2.0 Release Candidate 4 .

Tryby pracy serwera

Serwer Firebird dostępny jest w trzech architektu-

rach: Classic Server , Superserver oraz Embedded

Server .

Classic Serwer jest najstarszą wersją serwe-

ra. Dla każdego nowego połączenia z bazą tworzo-

ny jest w systemie operacyjnym oddzielny proces ob-

Tabele pochodne

Jedną z ciekawych nowości jest mechanizm ta-

bel pochodnych (ang. derived tables ). Jest to możli-

wość użycia zagnieżdżonych instrukcji SQL SELECT

w sekcji FROM.

Tabele pochodne można również zagnieżdżać

wielokrotnie. Ilustruje to Listing 2.

Autor jest programistą z ponad dwudziestoletnim sta-

żem. Od 10 lat pracuje w irmie REKORD Systemy In-

formatyczne Sp. z o. o. w Bielsku-Białej. Od kilku lat

programuje niemal wyłącznie w Delphi tworząc bibliote-

ki, komponenty, a także programy bazodanowe współ-

pracujące z serwerami InterBase oraz Firebird. Prowa-

dzi autorską stronę poświęconą programowaniu w Del-

phi oraz serwerowi Firebird – http://gskoczylas.rekord.pl

Protokół XNET dla połączeń

lokalnych w Windows

Firebird do połączeń lokalnych, gdy aplikacja

i serwer są na tym samym komputerze, używa in-

www.sdjournal.org Software Developer’s Journal 11/2006

H istoria serwera Firebird sięga 1984 roku. Wte-

Firebird SQL

Listing 2. Agregowanie danych z tabeli pochodnej

Listing 4. Składnia instrukcji COMMENT

SELECT

DT.FIELDS,

Count ( * )

FROM

( SELECT

R.RDB$RELATION_NAME,

Count ( * )

FROM

RDB$RELATIONS R

JOIN RDB$RELATION_FIELDS RF ON ( RF.RDB$RELATION_NAME

= R.RDB$RELATION_NAME )

COMMENT ON DATABASE IS { 'txt' | NULL };

COMMENT ON <basic_type> name IS { 'txt' | NULL };

COMMENT ON COLUMN tblviewname.ieldname IS { 'txt' | NULL };

COMMENT ON PARAMETER procname.parname IS { 'txt' | NULL };

W przypadku serwera Firebird dostępne funkcje inter-

fejsu programowego (ang. application programming in-

terface (API) ) można podzielić na dwie grupy. Pierwsza

to funkcje podstawowe, związane z modyikowaniem da-

nych oraz struktur danych. Druga grupa to funkcje serwi-

sowe pozwalające, na przykład, zarządzać użytkownika-

mi serwera, wykonać kopię bezpieczeństwa bazy danych

(ang. backup ) i tym podobne.

Wszystkie wersje serwera Firebird udostępniają te sa-

me funkcje podstawowego interfejsu programowego. Jed-

nak w Classic Server 1.x niektóre funkcje serwisowe nie

były zaimplementowane. Począwszy od wersji 2.0 wszyst-

kie funkcje interfejsu programowego są w pełni zaimple-

mentowane we wszystkich odmianach serwera Firebird.

GROUP BY

R.RDB$RELATION_NAME ) AS DT ( RELATION_NAME, FIELDS )

GROUP BY

DT.FIELDS

nego protokołu niż dla połączeń zdalnych. Protokół stoso-

wany w dotychczasowych wersjach serwera został zastą-

piony przez nowy protokół XNET. Ma on funkcjonalność

zbliżoną do dotychczasowego protokołu. Różni się od nie-

go następującymi cechami:

Bezpieczniejszy tryb serwisowy

W niektórych sytuacjach potrzebne jest zagwarantowanie, że

do serwera nie jest podłączony żaden inny użytkownik. Jedną

z takich sytuacji jest potrzeba weryikacji bazy danych (ang.

database validation ). Często również podczas aktualizowania

struktur bazy danych bezpiecznie jest zablokować możliwość

pracy użytkownikom do czasu jej zakończenia.

Dotychczas serwer Firebird oferował funkcję przełą-

czenia bazy w tryb pracy jednostanowiskowej (ang. data-

base shutdown ). Po przełączeniu w ten tryb z bazą danych

mógł się połączyć jedynie administrator serwera (użytkow-

nik SYSDBA). Nie był to jednak w pełni tryb jednostanowi-

skowy, ponieważ w tym trybie mogło z bazą jednocześnie

być połączonych dowolnie wielu użytkowników SYSDBA.

W przypadku dużej instytucji nie dawało to gwarancji, że

z bazą danych jest rzeczywiście cały czas połączony tylko

jeden użytkownik.

W serwerze Firebird 2.0 oprócz dotychczasowych trybów

wprowadzono nowy tryb pracy jednostanowiskowej. W tym

nowym trybie serwer gwarantuje, że z bazą danych może się

połączyć tylko jeden użytkownik SYSDBA.

• jest dostępny nie tylko w Superserver i Embedded Se-

ver , ale również w Classic Server ,może być wykorzy-

stywany w nieinteraktywnych usługach i sesjach termi-

nalowych;

• eliminuje blokady w przypadku wielu jednoczesnych połą-

czeń, jest nieco szybszy.

Niestety XNET nie jest zgodny z dotychczasowym protoko-

łem. Oznacza to, że w przypadku aktualizacji serwera do naj-

nowszej wersji konieczna jest również aktualizacja bibliotek

klienta. W przeciwnym razie lokalne połączenia z serwerem

nie będą dostępne.

Wydaje się, że w praktyce nie powinno to stanowić

większego problemu. Jeżeli jednak z jakiegoś powodu nie

będzie możliwe zaktualizowanie biblioteki klienta to za-

wsze można zastąpić połączenie lokalne przez połącze-

nie zdalne, wskazując komputer localhost (lub adres IP

127.0.0.1).

Pełna zgodność API

Jak już wcześniej napisałem, z punktu widzenia programisty

zazwyczaj nie ma znaczenia jaka jest architektura serwera Fi-

rebird, z którą ma program współpracować. W wersjach ser-

wera niższych niż 2.0 czasem jednak miało to znaczenie.

Usprawniony optymalizator

W nowej wersji serwera Firebird zaimplementowano wiele

usprawnień również w optymalizatorze zapytań. Poprawione

zostało między innymi weryikowanie warunków z operatora-

Listing 3. Indeksowanie w oparciu o wyrażenie

indeksujące

CREATE INDEX IDX1 ON T1

COMPUTED BY ( UPPER ( COL1 COLLATE PXW_PLK )) ;

COMMIT ;

/**/

SELECT * FROM T1

WHERE UPPER ( COL1 COLLATE PXW_PLK ) = 'CZĘŚĆ'

– PLAN ( T1 INDEX ( IDX1 ))

Listing 5. Składnia instrukcji EXECUTE BLOCK

EXECUTE BLOCK [ ( param datatype=?, param datatype=?, ... ) ]

[ RETURNS ( param datatype, param datatype, ... ) ]

[ DECLARE VARIABLE var datatype; ...]

BEGIN

...

END

Software Developer’s Journal 11/2006

www.sdjournal.org

Bazy

danych

Listing 6. Przykład użycia instrukcji EXECUTE BLOCK

256 bajtów. W niektórych sytuacjach jego maksymalna

efektywna długość była jeszcze krótsza. Obecnie maksy-

malna wielkość klucza indeksowego zależy wyłącznie od

wielkości strony bazy danych.

Dotychczas indeksy można było budować w oparciu o po-

la bazy danych. W wielu przypadkach bardzo przydatną no-

wością będzie nowa możliwość indeksowania w oparciu o wy-

rażenie indeksujące.

Jak widać na Listingu 3, korzystając z tego mecha-

nizmu można, na przykład, utworzyć indeks nie rozróż-

niający wielkości liter. Jest to szczególnie przydatna ce-

cha. Często trzeba w bazie znaleźć informacje teksto-

we, na przykład kontrahenta o danej nazwie. Użytkownik

najczęściej chce znaleźć odpowiednie dane bez rozróż-

niania wielkości liter. W tym celu dotychczas można było

w instrukcji SQL SELECT w klauzuli WHERE użyć funkcję Up-

per , na przykład SELECT * FROM Kontrahenci WHERE Upper(

Nazwa) STARTING WITH 'G' . Jeżeli w bazie jest zdeiniowany

indeks według pola Nazwa to można by oczekiwać, że in-

strukcja będzie działać szybko. Niestety użycie funkcji Up-

per powoduje, że serwer nie może skorzystać z tego in-

deksu. Aby zapewnić szybkie wyszukiwanie danych nale-

żało wymusić zapisywanie nazw kontrahentów wielkimi li-

terami. Alternatywnym rozwiązaniem było utrzymywanie

dodatkowego pola zawierającego kopię nazwy kontrahen-

ta zapisaną wielkimi literami i wyszukiwanie w tym dodat-

kowym polu. Począwszy od Firebird 2.0, dzięki możliwości

tworzenia indeksów w oparciu o wyrażenia, można to bę-

dzie robić znacznie prościej.

Mechanizmy obsługi indeksów w serwerze Firebird 2.0

zostały gruntownie przeprojektowane. Oprócz opisanych

rozszerzeń cechuje je znacznie szybsze działanie, a także

sprawniejsze zarządzanie wieloma powtarzającymi się warto-

ściami kluczy oraz wartościami NULL .

EXECUTE BLOCK

DECLARE VARIABLE REJ CHAR ( 3 ) ;

BEGIN

FOR

SELECT DISTINCT N2.REJESTR FROM NOTY N2 INTO :REJ

DELETE FROM NOTY N

WHERE N.REJESTR=:REJ

AND N.DATA_UTW<> ( SELECT MAX ( N1.DATA_UTW ) FROM NOTY

N1 WHERE N1.REJESTR=N.REJESTR ) ;

END

mi OR , IN , IS NULL , STARTING WITH , łączenie tabel przy pomocy

JOIN i wiele innych.

Niektóre z tych usprawnień działają tylko wtedy gdy plik

bazy danych ma nowy nagłówek bazy. Aby w pełni wykorzy-

stać możliwości serwera zalecane jest wykonanie kopii do-

tychczasowej bazy danych (ang. backup ) i jej odtworzenie

(ang. recreate ) pod kontrolą serwera Firebird 2.0.

Bezpieczeństwo

W nowym serwerze wprowadzono również zmiany związa-

ne z bezpieczeństwem. Część z tych zmian związana jest

z bazą użytkowników serwera. Dotychczas można było

połączyć się z bazą security.fdb tak jak z każdą inną bazą

danych. Obecnie baza użytkowników nazywa się securi-

ty2.fdb i można z tej bazy korzystać wyłącznie przy pomo-

cy odpowiednich funkcji interfejsu programowego serwera.

Hasła użytkowników są obecnie szyfrowane lepszym algo-

rytmem. Utrudnia to złamanie haseł w przypadku gdyby

baza użytkowników została skradziona.

Zmodyikowana została również struktura bazy użyt-

kowników serwera. Dotychczas prawo do modyikowania

tej bazy miał wyłącznie administrator SYSDBA. Wprowa-

dzone zmiany spowodowały, że obecnie każdy użytkow-

nik może zmienić swoje własne hasło. Oczywiście SYSD-

BA nadal może między innymi zmieniać hasła dowolnego

użytkownika.

Utrudniono również łamanie hasła użytkownika meto-

dą sprawdzania wszystkich możliwych kombinacji znaków

(ang. brute-force hacking ). Po kilku nieudanych próbach

zalogowania się użytkownik i odpowiedni adres IP jest blo-

kowany na pewien czas uniemożliwiając w tym czasie za-

logowanie się z zablokowanym identyikatorem użytkowni-

ka lub z zablokowanego adresu IP.

Niestety, serwer nadal analizuje tylko pierwsze osiem znaków

hasła. W przypadku dłuższych haseł pozostałe znaki nadal są

ignorowane. Jest to poważna wada jeżeli ktoś planowałby udo-

stępnić dane bezpośrednio przez internet. W takim przypadku za-

leca się stosowanie oprogramowania tunelującego (ang. IP-tun-

neling software ) lub tworzenie programów tak aby baza danych

nie była nigdy bezpośrednio dostępna przez internet.

Nowe możliwości deiniowania

struktury bazy danych

W serwerze Firebird 2.0 zaimplementowane zostało wiele no-

wych możliwości deiniowania struktury bazy danych. Są to ta-

kie instrukcje jak CREATE SEQUENCE (analogiczne do CREATE GE-

NERATOR ), RECREATE EXCEPTION , ALTER EXTERNAL FUNCTION , RECRE-

ATE TRIGGER i podobne.

Ciekawą nową instrukcją jest instrukcja COMMENT . Jej skład-

nię prezentuje Listing 4.

Instrukcja ta pozwala powiązać komentarze ze strukturami

danych. Jest to przydatna możliwość w wielkich bazach danych

zawierających setki tabel, procedur, wyzwalaczy (ang. triggers )

i innych obiektów. Komentarze mogą zawierać dowolny opis ko-

mentowanych struktur, na przykład dodatkowe założenia doty-

czące danych zapisywanych w komentowanej tabeli.

Listing 7. Deinicja funkcji rozpoznającej wartości NULL

zgodnie z nowymi zasadami

DECLARE EXTERNAL FUNCTION substr

CSTRING ( 255 ) NULL , SMALLINT, SMALLINT

RETURNS CSTRING ( 255 ) FREE_IT

ENTRY_POINT 'IB_UDF_substr'

MODULE_NAME 'ib_udf' ;

Nowe możliwości indeksowania danych

Dotychczas niekiedy uciążliwym ograniczeniem był limit

wielkości klucza indeksowego, który nie mógł przekroczyć

www.sdjournal.org Software Developer’s Journal 11/2006

Firebird SQL

Tabela 1. Porównanie niektórych cech Firebird 1.5 oraz 2.0

Cecha

Firebird 1.5

Firebird 2.0

Pełna zgodność funkcji w Superserver, Classic

Server i Embedded Server

Połączenia lokalne Tylko Superserver i Embedded Server Dostępne również w Classic Server

Tryb jednostanowiskowy Częściowo, po shutdown z bazą da-

nych może się połączyć wielu użytkow-

ników SYSDBA

Niektóre funkcje nie są dostępne w

Classic Server

Dodatkowy tryb w pełni blokujący dostęp innych

użytkowników do bazy danych

Wykonywania kopii bazy da-

nych

Możliwość wykonania wyłącznie peł-

nej kopii

Możliwość wykonania pełnej lub przyrostowej ko-

pii bazy

Rozmiar kluczy indeksowych 256 bajtów

więcej, zależy od wielkości strony bazy danych

(w chwili pisania tego artykułu brak dokładnych

informacji)

Nadawanie haseł użytkownikom Tylko SYSDBA może nadawać i zmie-

niać hasła użytkowników

SYSDBA może nadawać i zmieniać hasła

wszystkich użytkowników, każdy użytkownik mo-

że zmienić swoje hasło

Bezpieczeństwo haseł Hasła w bazie użytkowników są zaszy-

frowane słabym algorytmem

Hasła są szyfrowane lepszym algorytmem

Włamanie przez sprawdzanie

wszystkich kombinacji znaków

w haśle

Brak ochrony

Po przekroczeniu limitu prób konto użytkownika i

adres IP są na pewien czas blokowane

Rozpoznawanie wartości NULL

w funkcjach UDF

Poprzez deskryptory, skomplikowane Wygodne, poprzez wskaźnik

Jeżeli mamy wielu klientów korzystających z naszych

programów to korzystne jest modyikowanie struktur ba-

zy danych przy pomocy skryptów SQL. Przetestowa-

ny skrypt można później uruchomić u każdego klienta

i w wysoce niezawodny sposób zaktualizować odpowied-

nie struktury baz danych. Czasem się zdarza, że trzeba

w bazie danych nie tylko zmienić struktury, ale również

wykonać pewne modyikacje w samych danych (np. na-

prawiające uszkodzone dane). Dotychczas w takich sytu-

acjach w skrypcie SQL trzeba było zdeiniować procedu-

rę modyikującą dane. Następnie skrypt wykonywał taką

procedurę i na końcu usuwał ją z bazy danych. Począw-

szy od wersji Firebird 2.0 w takiej sytuacji można wyko-

rzystać o wiele wygodniejszy mechanizm: można skorzy-

stać z instrukcji EXECUTE BLOCK . Składnię tej instrukcji pre-

zentuje Listing 5.

Jak widać, instrukcja ta przypomina deinicję procedury.

I rzeczywiście, jej działanie przypomina opisany wyżej przy-

padek z deiniowaniem tymczasowej procedury. W Listingu 6

zamieszczony został praktyczny przykład wykorzystania tej

instrukcji. Na skutek błędu w programie pewne dane w ba-

zie danych zostały niepoprawnie zapisane. Błąd w programie

R E K L A M A

Dostępność API

Bazy

danych

został poprawiony, ale trzeba jeszcze usunąć z bazy danych

błędne dane. Takie działanie trzeba wykonać u kilku klientów

więc należy przygotować odpowiedni skrypt SQL.

Gdy już mowa o wykonywaniu skryptów SQL to w ser-

werze Firebird 2.0 wprowadzono jeszcze jedno bardzo

wygodne usprawnienie. Mianowicie w przypadku błędu

w skrypcie serwer wskazuje numer wiersza zawierające-

go błąd. Dotychczasowy sposób sygnalizowania błędów

w przypadku powodował, ze w dużych skryptach znalezie-

nie błędu bywało nieraz kłopotliwe.

W Sieci

• http://www.irebirdsql.org – podstawowa strona serwera Firebird;

• http://www.ibphoenix.com – portal integrujący użytkowników

serwera Firebird;

• http://en.wikipedia.org/wiki/Firebird_%28database_server%29

– artykuł o Firebird w angielskiej wersji Wolnej Encyklopedii

Wikipedia;

• http://pl.wikipedia.org/wiki/Firebird – artykuł o Firebird w pol-

skiej wersji Wolnej Encyklopedii Wikipedia;

• http://irebird.sourceforge.net/devel/engine/roadmap2006.html

– plany rozwoju serwera Firebird;

• http://www.irebirdsql.org/pdfmanual/MSSQL-to-Firebird.pdf –

dokument opisujący migrację z MS SQL do Firebird;

• http://www.irebirdsql.org/pdfmanual/Firebird-nbackup.pdf –

dokumentacja programu do wykonywania przyrostowych ko-

pii bazy danych;

• http://www.irebirdnews.org/docs/fb2min_pl.html – Poznaj Fi-

rebird w 2 minuty (po polsku).

Przyrostowa kopia zapasowa

Razem z serwerem Firebird 2.0 dostarczane są nowe na-

rzędzia do wykonywania kopii bazy danych. Dotychczas

można było wykonać jedynie pełną kopię bazy danych. Za-

zwyczaj nie stwarzało to większych problemów bo wyko-

nywanie kopii bazy danych trwa stosunkowo szybko i moż-

na je wykonywać nie przerywając pracy użytkowników.

W przypadku bardzo dużych baz danych brakowało jednak

możliwości wykonywania przyrostowej kopii bazy danych

(ang. incremental backup ). Obecnie dzięki nowym progra-

mom NBak i NBackup jest już taka możliwość. Kopię przy-

rostową również można wykonywać bez przerywania pra-

cy użytkowników.

nia instrukcji deiniującej funkcje UDF. Po każdym para-

metrze można dopisać NULL informując w ten sposób ser-

wer, że funkcja jest przygotowana do tych nowych mecha-

nizmów. Jeżeli dodatkowe słowo NULL nie występuje to ser-

wer przekazuje do funkcji wartości parametrów zgodnie

z dotychczasowymi zasadami, czyli wartość NULL jest prze-

kazywana jako pusty napis lub liczba zero itp. Listing 7 za-

wiera deinicję funkcji UDF „świadomej” nowego sposobu

sygnalizowania wartości NULL .

64 bity

Twórcy serwera Firebird planowali w wersji 2.0 zapewnić

wsparcie dla platform 64-bitowych. Udało się to zrealizować

tylko częściowo. W 64-bitowym systemie Linux dostępny jest

zarówno Superserver jak i Classic Server . Były one dotych-

czas testowany wyłącznie na AMD64.

W systemie Windows stworzenie i testowanie serwera

64-bitowego było utrudnione zarówno przez brak dobrych

64-bitowych kompilatorów C/C++, jak i przez brak odpo-

wiedniego wsparcia dla 64-bitowego systemu operacyjnego.

W tych okolicznościach zdecydowano o odłożeniu premie-

ry 64-bitowego serwera Firebird dla Windows. Autorzy mają

nadzieję, że w niedalekiej przyszłości będą mogli udostęp-

nić pierwsze testowe wersje 64-bitowego serwera dla tego

systemu operacyjnego.

Podsumowanie

Serwer Firebird ma rzeszę wiernych użytkowników,

zwłaszcza spośród użytkowników narzędzi programi-

stycznych irmy Borland. Nowości wprowadzone w wersji

2.0 serwera pokazują, że decyzja o zastosowaniu go ja-

ko elementu tworzonych aplikacji nie była chybiona. Ser-

wer rozwija się systematycznie i co jakiś czas powstają

nowe wersje udostępniające nowe możliwości, charakte-

ryzujące się większym bezpieczeństwem i większą wy-

dajnością. Jest jeszcze wiele elementów wymagających

ulepszenia. Jednym z takich elementów jest lepsza ob-

sługa systemów wieloprocesorowych przez Superserver .

Przydałby się wbudowany mechanizm kompresji danych

w polach BLOB. Kolejny element wymagający jak naj-

szybszego usprawnienia to większe bezpieczeństwo ba-

zy danych. Przydałaby się możliwość szyfrowania danych

w bazie. Również sprawdzanie tylko pierwszych ośmiu

znaków hasła powoduje, że serwer jest stosunkowo mało

odporny na próby włamania.

Twórcy serwera są świadomi tych niedostatków. Te i wiele

innych nowości obiecują zrealizować w następnej wersji ser-

wera. Udostępnienie Firebird 3.0 planowane jest już po roku

od zakończenia prac nad wersją 2.0.

Najprawdopodobniej dotychczasowi użytkownicy szyb-

ko zdecydują się na zastosowanie nowej wersji serwera

ze względu na jego większe bezpieczeństwo, wydajniej-

sze działanie oraz szereg nowych przydatnych mechani-

zmów. Nowe możliwości wprowadzone w Firebird 2.0 mo-

gą również zachęcić wielu nowych użytkowników do jego

używania. n

Funkcje UDF

Funkcjonalność serwera Firebird można zwiększać po-

przez dołączanie do niego własnych bibliotek funkcji UDF

(ang. User-Deined Functions ). W systemie Windows są to bi-

blioteki DLL, a w Linux – SO.

W serwerze Firebird 1.0 autorzy funkcji UDF nie mie-

li żadnych możliwości odróżnienia parametrów o wartości

NULL od pustych napisów, liczb zero itp. W wersji 1.5 udo-

stępniony został nowy mechanizm przekazywania para-

metrów przez deskryptory. Pozwala on wprawdzie spraw-

dzić czy parametr ma wartość NULL , ale korzystanie z de-

skryptorów jest skomplikowane i przez to uciążliwe. W Fi-

rebird 2.0 wprowadzony został prostszy mechanizm. Ser-

wer przekazuje parametry do funkcji UDF przez referencję.

W praktyce oznacza to, że używane są wskaźniki. Dla war-

tości NULL serwer może przekazywać pusty wskaźnik.

Nowy mechanizm mógłby spowodować, że dotychcza-

sowe biblioteki funkcji UDF przestałyby działać popraw-

nie dla wartości NULL . Dlatego rozszerzona została skład-

www.sdjournal.org Software Developer’s Journal 11/2006

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: