Programowanie ma zadziwiająco mało struktur:
Singleton (jeden obiekt):
.
Lista(Szeregowo ustawione obiekty różnych typów):
...........................
Tablica(Albo lista list):
...........................
...........................
...........................
Drzewo (Z bierzącego węzła jest dostęp do N węzłów potomnych):
.
. .
. .
. .
Graf (Jak wyżej ale węzeł może być swoim węzłem potomnym).
Naturalną strukturą dla obiektu jest graf. Widać to szczególnie w javie*, ale i cpp ma podobną. Dla języków niskiego poziomu naturalną strukturą jest lista.
Można mapować jedne strukturę na drugą, ale to zawsze jest robota. Mapowanie drzewa na ścieżkę od jednego węzła do drugiego (ale ścieżkę przepływu danych, która nie jest ścieżką po gałęziach), zajęło mi z pół godziny roboty i parędziesiąt linijek mojego dość oszczędnego kodu... Mapowanie np. Vectora na tablicę to jest jedna linia kodu..
I teraz co za debil wymyślił SQL? Albo inaczej co za debil wymyślił mapowanie obiektów na SQL...
To jest tak nienaturalna struktura. Nie da się wrzucić obiektu w tablicę. Chyba że statycznego (ale takie są nudne i nieprzydatne). Żeby to miało jakieś wydajnościowe uzasadnienie... Ale nie! Sql nie jest bardzo wydajny, a jeśli jest więcej czasu traci się na obsługę mapowania Baza Danych <-> Obiekt niż się oszczędza na odczycie danych....
Doh!!
Bo mapowaniem Baza Danych <-> język ją przetwarzający zajmuje się serwer integracji. A przy jego oprogramowaniu to java jest niskopoziomowa ;).
Dlatego ostatnio tak modny jest XML, jest zajebiście nieoptymalnym wydajnościowo formatem (jak wszystkie tekstowe). Ale mapowanie Java <-> XML jest mapowaniem 1 do 1. Kod mapujący takie coś to i maszyna napisze (i owszem --- piszą ;)).
* Obiekty są tak na prawdę zbiorami odnośników do innych obiektów. Liściami tego drzewa są typy prymitywne.
