Około 90% aplikacji tworzonych za pomocą Delphi w mniejszym lub większym stopniu opiera się o bazy danych. Z tego powodu wraz z rozwojem Delphi i nowymi trendami, a także możliwościami obsługi baz danych pojawiały się kolejne generacje komponentów bazodanowych. Poprzez komponenty bazodanowe należy rozumieć zarówno komponenty umożliwiające nawiązanie połączenia z bazami danych jak i komponenty przetwarzające dane czyli DataSet-y.

       2.1   BDE
       2.2   ADO
       2.3   DBX
       2.4   ClientDataSet

2.1 BDE

Najstarszymi komponentami bazodanowymi w Delphi są komponenty BDE (Borland Database Engine), które były pierwszym stworzonym na tak dużą skalę uniwersalnym silnikiem bazodanowym dla programistów. Technologia ta powstawała przez wiele lat i z czasem przyjęte w niej rozwiązania okazały się mało wygodne i mało nowoczesne w dzisiejszych czasach, choć początkowo była to prawdziwa rewolucja w sposobie dostępu do baz danych. BDE łączyło w sobie dwie starsze technologie bazodanowe oraz wprowadzało trzecią nową. Dokładniej chodzi tutaj o wykorzystanie ODBC oraz IDAPI stworzonych na początku lat 90-tych. Nowym rozwiązaniem w BDE były bezpośrednie sterowniki dla kilku najpopularniejszych w tamtych czasach serwerów (sterowniki te zostały nazwane SQL Link). BDE potrafi bardzo dużo, ale przez to jego wewnętrzna budowa jest bardzo skomplikowana, co skutkowało trudnością w jej rozwijaniu. Zarówno ODBC jak IDAPI pozwalały wykorzystać plikowe bazy danych, a mechanizmy dostarczane w BDE umożliwiały wykorzystywanie ich w podobny sposób jak serwery SQL. Ułatwiało to migrację rozwiązań plikowych do serwerów SQL.

Mimo wielu zalet BDE trzeba pamiętać, że od stworzenia tych komponentów minęło kilkanaście lat, a obecnie używając zwrotu bazy danych mamy na myśli głownie bazy oparte o serwery SQL. Firma Borland analizując wysokie koszty rozwijania BDE zaczęła tworzyć nowoczesną i bardziej elastyczną technologię dbExpress. Rozwój BDE był stopniowo spowalniany, aż w roku 2002 został oficjalnie wstrzymany. Komponenty te są umieszczane w środowisku tylko i wyłącznie w celu uzyskania kompatybilności wstecznej, czyli umożliwienia programistom pracy ze starymi projektami, które budowano w oparciu o BDE. Należy mieć też świadomość, że planowano wycofać mechanizm ODBC w najnowszym systemie operacyjnym Windows 7 i tylko po protestach użytkowników został ten mechanizm przywrócony. Należy się jednak spodziewać że kolejna odsłona systemu operacyjnego Windows nie będzie posiadała ODBC, a przez to aplikacje używające BDE nie będą pracowały w tym systemie.

powrót na górę strony

2.2 ADO (dbGo)

Po sukcesie BDE (opartego o ODBC i łącza SQL Link) Microsoft opracował wzorowany na nim, ale nowocześniejszy standard połączeń do baz danych o nazwie ADO. Jest to technologia w której można również korzystać z połączeń ODBC, plikowych baz danych, a najnowocześniejsze są silniki: nazywane OLE DB (analogiczne rozwiązanie jak SQL Link w BDE) oraz Microsoft Jet przeznaczony do obsługi baz Access. ADO jest rozwiązaniem w pełni obiektowym i zawiera swoje własne klasy przypominające TDataSet (nazywane RecordSet). Aby umożliwić programistom Delphi/C++Builder korzystanie z ADO w taki sam sposób jak z BDE wprowadzono komponenty opakowujące możliwości ADO bazujących na klasycznym TDataSet. Rozwiązanie to zostało początkowo nazwane ADO Express, a później dbGo. Standard ten był o tyle prostszy w użyciu, że najczęściej nie wymagał instalowania czegokolwiek na komputerze klienta oraz uwzględniał nowe funkcjonalności pojawiające się wraz z rozwojem baz danych. pory technologie ADO jest do dzisiaj używana z powodzeniem, lecz warto wiedzieć, że niedawno jego rozwój został zatrzymany, a Microsoft już od kilku lat rozwija alternatywną technologię bazodanową dla platformy .NET, nazywaną ADO.NET. Przykładowo wraz z rozwojem serwera MS SQLServer (Microsoft) pojawiły się nowe tryby izolacji transakcji jak Snapshot, lecz nie zostały one zaimplementowane w standardowych sterownikach OLE DB, a prowadzony został nowy silnik nazywany Native Client. Z racji zamknięcia rozwoju tego standardu być może za kilka lat technologia ADO podzieli los ODBC. Należy się spodziewać coraz większej różnicy pomiędzy możliwościami baz danych, a możliwościami komponentów opartych o ten standard. Z tego powodu nie warto zaczynać nowych projektów standardu opartych o ten standard, a także projekty istotne dla firmy powinny być migrowane na nowsze generacje komponentów.

powrót na górę strony

2.3 DBX (dbExpress)

W roku 2000 Borland zaproponował nową generację komponentów połączeniowych do baz danych. Wykorzystując doświadczenia i wnioski z prac nad BDE rozdzielono warstwę transportową danych od warstwy przetwarzania. Wcześniejsze komponenty typu DataSet potrafiły realizować obie funkcje, co powodowało, że technologie wspierające je były złożone i trudne w rozwoju. Dodatkowo sytuację BDE i jemu podobnych rozwiązań pogarszał fakt, że pisanie i aktualizowanie sterowników wpierających kilka serwerów SQL było zadaniem trudnym. Dlatego w aplikacjach opartych o dbExpress zazwyczaj wykorzystuje się dwa "datasety": transportowy i przetwarzający. Ten drugi jest uniwersalny i nie zależny od konkretnego serwera SQL, jest to opisywany dalej komponent ClientDataSet. Dzięki temu "datasety" dbExpress-owe (transportowe) są proste i działają szybko. Bardzo ważnym jest fakt, że sterowniki dbExpress w maksymalny sposób wykorzystują natywne sterowniki DLL dostarczane przez producentów, dlatego dla połączenia z serwerem InterBase jest wykorzystywany sterownik dbExpress dla InterBase (dbxint.dll) oraz natywna biblioteka (gds32.dll). Rozwiązanie takie zapewnia wykorzystanie pełnej prędkości transmisji danych jaką dostarcza biblioteka kliencka. W technologii dbExpress wprowadzono uniwersalny data set transportowy (komponent TSQLDataset), który pozwala pobierać dowolne dane w taki sam sposób niezależnie od tego z jakiej bazy lub z jakiego serwera one pochodzą. Dzięki temu mamy możliwość "przełączania" serwera SQL, z którym pracujemy, poprzez zmianę danych połączeniowych, a cały utworzony kod związany z komponentami DBX może działać tak samo niezależnie od tego czy jesteśmy podłączeni do Oracle, MS SQLServer czy Firebird. Jedyne różnice jakie mogą się pojawić to specyficzne typy danych, które są dostępne w jednym a nie dostępne w drugim.

powrót na górę strony

2.4 ClientDataSet

W celu oddzielenia warstwy prezentacji od struktur danych standardowo w środowiskach Delphi / C++Builder stosuje się układ komponentów:

konektor -> zbiór danych -> "powiadamiacz" -> wizualizator.

Konektor służy do połączenia i pobrania danych z serwera SQL, przykładowo to może być komponent TSQLConnection. Zbiór danych jest miejscem w którym przechowuje się dane i zapisuje wynik pracy z danymi. Może to być TSQLDataSet, lecz z racji możliwości najbardziej zalecana jest trójka: TSQLDataSet, TSQLProvider i TClientDataSet. "Powiadamiacz" to po prostu TDataSource - komponent pośredniczący pomiędzy zbiorami danych a komponentami wyświetlającymi dane. W momencie zmian w zbiorze danych "powiadamiacz" informuje wszystkie powiązane komponenty służące do wizualizacji danych o zmianach, tak aby komponenty mogły uaktualnić swój "wygląd". Wizualizatory to wszelkie komponenty pokazujące dane, czyli pola edycyjne, nawigatory, siatki DBGrid itd.

Dodatkowo opisana wcześniej przykładowa trójka zapewnia oddzielenie warstwy transportowej danych od warstwy przetwarzania danych. Dzięki podziałowi komponentów na pobierające dane, przechowujące dane i obrazujące dane bardzo łatwo można oddzielić poszczególne warstwy aplikacji i ich funkcjonalności. Bardzo ważną rolę w tym układzie pełni ClientDataSet, który zapewnia wysoką kontrolę pobieranych danych oraz pozwala na przetwarzanie danych w pamięci aplikacji, bez ciągłego obciążania serwera SQL, co ma ogromny wpływ na optymalizacje pobierania i przetwarzania danych.

Komponent TClientDataSet jest najbardziej rozbudowanym komponentem typu DataSet pozwalającym chociażby na pobieranie danych paczkami, sortowanie po stronie klienta, tworzenie indeksów "w locie", filtrowanie danych, tworzenie pól wyliczalnych, grupowanie danych, czy zarządzanie danymi gromadzonym w pamięci, za przed i po zmianie. Te możliwości pozwalają na szeroką "obróbkę" uzyskanych danych, a przez to ograniczają czas i częstotliwość połączeń do serwera SQL w celu pobrania kolejnych danych (np. tych samych lecz inaczej posortowanych).

Równocześnie TClientDataSet może pracować w trybie bezpołączeniowym, czyli po pobraniu wiadomości można rozłączyć się z serwerem SQL, a z danymi pracować lokalnie. Jak wiadomo liczba równoczesnych połączeń z serwerem ma wpływ nie tylko na jego skalowalność, ale bardzo często na inne aspekty, takie jak liczba dostępnych licencji. Do zalet komponentu TClientDataSet należy również, bardzo wygodna praca z plikami lokalnymi. Dane i opisujące struktury można wczytywać i zapisywać do plików plików XML lub plików binarnych. Możliwe jest to zarówno w momencie, gdy możliwe jest nawiązanie połączenia z serwerem lub gdy nie jest to możliwe. Rozwiązanie takie pozwala łatwo pobrać dane z serwera do swego rodzaju "podręcznej aktówki" i przetwarzać je bez połączenia. Wszystkie zmiany przechowywane są w postaci tzw. delty, która w dowolnym momencie może zostać zapisana w pliku lub odesłana do serwera. Dzięki zapamiętywaniu delty dane można przeglądać w wersji sprzed i po zmianie. Można te zmiany wycofać w całości lub kolejno. Dopiero przez wydanie polecenia utrwalenia zmian ("Apply Updates") następuje synchronizacja z serwerem SQL. Ze względu na wprowadzony model bezpołączeniowy dużo wysiłku wprowadzono również do bezpiecznej kontroli czy zmianie przez innych użytkowników nie uległy wiersze, które są synchronizowane.

powrót na górę strony