ODBMS – pomysł

Ostatnie kombinowanie z indeksami nasunęło mi pomysł na zmierzenie się z problemem obiektowej bazy danych. Oczywiście całość w javie. Pomysł pozbawiony sensu, bo Sun określił już dość dawno specyfikację JDO, ale ja chciałbym użyć trochę innego podejścia.

Dlaczego nie JDO?

Po pierwsze JDO jest przestarzałe. Wiele elementów jest napisanych z użyciem pomysłów z Javy 2, pojawiają się stale inty zamiast enumów, toporna składnia zapytań.
Po drugie JDO jest „umysłowo ograniczone” i nijak ma się do na przykład JPA. Jakoś nie widzę możliwości integracji tych dwóch technologii.

Zło RDBMS

Jeżeli myślimy o bazie danych to przede wszystkim myślimy o sposobie składowania i wyszukiwania danych. Co więcej wielu ludzi kojarzy bazy danych z językiem SQL, a nie ma pojęcia, że istnieją inne rozwiązania. Systemy relacyjne, czyli właśnie te o których mówimy mówiąc o SQL, mają kilka drobnych wad. Niewątpliwie najpoważniejszą z nich jest bardzo skomplikowana i nie naturalna składnia w momencie gdy chcemy uzyskać informacje o złożonej strukturze danych. Wracając do przykładu biblioteki najzdrowszym połączeniem było by takie:

CREATE table Ksiazki(
id int,
nazwa text NOT NULL,
aId int,
PRIMARY KEY(id)
);
CREATE table Autorzy(
id int,
imie text NOT NULL,
PRIMARY KEY(id)
);
ALTER TABLE Ksiazki ADD FOREIGN KEY (aId) REFERENCES Autorzy(id);

Zarówno tabela Ksiazki jak i tabela Autorzy reprezentują zwykłe POJO. Obecnie, żeby wybrać wszystkie książki jakiegoś autora należy, albo uruchomić taką potworę:

SELECT * FROM Ksiazki AS k LEFT JOIN Autorzy AS a ON a.id = k.aId WHERE a.id=2;

albo taką:

SELECT * FROM ksiazka AS k WHERE k.aId = (SELECT id FROM Autorzy WHERE id = 2);

albo kombinować z JPA, Hibernatem lub czymś podobnym. To ostatnie rozwiązanie jest najlepsze, ponieważ używamy już składni i sposobu myślenia właściwego rozwiązaniom obiektowym, ale nadal biblioteki te mapują obiekty na zwykłe tabele w RDBMS. A gdyby tak ominąć konieczność posługiwania się SQLem?

Czas na ODB

Niezłym podejściem jest zatem próba stworzenia własnej obiektowej bazy danych, która łączyła by elegancki interfejs JPA z brakiem przymusu stosowania SQLa. Baza taka musiała by spełniać kilka elementarnych założeń:

  • trwałość i integralność danych
  • mechanizmy dostępu i zarządzania użytkownikami
  • obsługa mechanizmów obiektowych, przede wszystkim dziedziczenia
  • równoległy dostęp do danych i obsługa transakcji
  • metody dodawania, modyfikacji, usuwania i dostępu do danych

W celu realizacji tych założeń potrzebne są pewne narzędzia:

  • menadżer obsługi plików danych
  • menadżer użytkowników
  • menadżer transakcji
  • menadżery utrwalania

pytanie czy znajdę czas…

2 myśli na temat “ODBMS – pomysł

  1. Masz za wąską kolumnę główną — obcina bloki <pre>, sprawiając że są nieczytelne.

  2. Wiem, obecnie zmieniam layout. Będzie ładniej i mniej topornie.

Napisz odpowiedź

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax