Dylemat obiektowy

Wbrew dość rozpowszechnionej opinii, obiektowa baza danych powinna być szybsza niż relacyjna

Wbrew dość rozpowszechnionej opinii, obiektowa baza danych powinna być szybsza niż relacyjna

W miarę jak firmy przebudowują swoje struktury, pojawia się pytanie czy należy używać relacyjnych, czy obiektowych baz danych jako części swej infrastruktury informatycznej. Dobry konsultant powinien odpowiedzieć: "To zależy".

Relacyjna baza danych, to taka składnica danych, z której aplikacja czyta i do której zapisuje swoje dane. Obiektowa baza danych to wirtualne rozszerzenie w pamięci twojej aplikacji. Obie mogą być używane w aplikacjach klient/serwer. Obiekty można przetworzyć na tabele bazy za pomocą metody enkapsulacji klas; tabele można utworzyć z podstawowych klas za pomocą wbudowanego SQL.

Serwery problemowe można zbudować na bazach obiektowych w celu obsługi aplikacji nieobiektowych. Różnica w architekturze powoduje konieczność rozstrzygania kompromisów inżynierskich.

Wbrew rozpowszechnionej opinii obiektowa baza danych powinna być szybsza niż relacyjna. Po znalezieniu podstawowego obiektu - np. KLIENT=Kowalski - dostępne są od razu wszystkie związane z nim obniekty, np. zamówienia.

W celu dokonania tej samej operacji, baza relacyjna musi wykonać wiele operacji wejścia/wyjścia, korzystać z wielu indeksów i zebrać dane w formie nowej tabeli.

Bazy obiektowe lepiej radzą sobie z informacją abstrakcyjną. Obiektowe bazy danych umożliwiają zwykle dziedziczenie i różnicowanie właściwości przechowywanych obiektów w ramach hierarchii klas. I tak, np. możliwe jest rozróżnianie w ramach klasy FIRMA tych firm, które są KLIENTAMI, i składają zamówienia, od dostawców, którzy dostarczają nam usługi i produkty. To samo można zrealizować za pomocą w pełni znormalizowanej bazy relacyjnej, ale wymaga to więcej planowania w tworzeniu wspólnych tabel, kluczy obcych, odpowiednich wyciągów i zapytań do bazy. Programista obiektowy pyta po prostu o pożądany obiekt.

Bazy obiektowe ułatwiają zmiany. Przypuśćmy, że KLIENT ma atrybut o nazwie LIMIT KREDYTU o ustalonej wartości. Przypuśćmy, że wartość tego limitu wyliczamy na podstawie historii kontaktów z klientem i sposobu wywiązywania się ze zobowiązań. Oznacza to, że LIMIT KREDYTU jest wartością dynamiczną. Ponieważ dobrze zaplanowana aplikacja obiektowa nigdy nie sięga bezpośrednio do wartości obiektu, zawsze korzystając z metody, to uaktualnienie słownika obiektów i zmiana definicji klasy KLIENT, realizuje nową regułę wyliczania kredytu.

Jednakże bazy obiektowe są niezbyt dojrzałe, ich właściwości różnią się między produktami, a standardów na razie nie widać.

Większość baz obiektowych korzysta jedynie z C++ i Smalltalka, podczas gdy w bazach relacyjnych dostępne są narzędzia 4GL, programy do tworzenia raportów i inne narzędzia. Jednoczesne korzystanie z tej samej instancji obiektu (wiele aplikacji sięga do niego) wymaga więcej wysiłku przy programowaniu obiektowym.

Systemy relacyjne zapewniają lepsze możliwości dystrybucji danych, narzędzia do strojenia bazy, backupu i odzyskiwania zawartości. Wiele dyscypliny i wysiłku programisty jest potrzebne do uzyskania takich samych wyników w bazach obiektowych.

W końcu, wiele możliwości baz obiektowych można zealizować w bazach relacyjnych, ale kosztem zmniejszenia wydajności i dużego wysiłku.

Tak więc, nim podejmiesz opracowanie aplikacji, zdecyduj się na architekturę techniczną i obieg informacji w przedsiębiorstwie. Wtedy będziesz mógł wybierać między różnymi technologiami, bez pogarszania parametrów technicznych projektowanej aplikacji.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200