🚀 go-pugleaf

Kuba Chabik/Duncan Pierce napisali:

> But I have heard about some pretty general techniques for 
> "objectising" a relational database (why would you want 
> to do this? nobody knows). 

Jakbym siebie slyszal.

> The obvious solution is to start by writing a class for 
> every database table.

Rzeczywiscie ten sposob na pierwszy rzut oka wydaje sie 
oczywisty. Kazda klasa posiada odpowiadajaca jej relacje,
co sprawia, ze pod wzgledem logicznym, modele relacyjny
i obiektowy sa zblizone. Problem zaczyna sie jednak w 
momencie, gdy pojawia sie dziedziczenie. Oto przyklad:

dane sa klasy

A <- B <- C <- D <- E 

gdzie <- oznacza dziedziczenie (A jest klasa pierwotna). 
Zgodnie z wczesniej przyjeta zasada "1 klasa 1 relacja" 
nasza RBD zawierac bedzie nastepujace relacje

Tab_A, Tab_B, Tab_C, Tab_D, Tab_E

Zalozmy, ze gdzies w naszym programie pojawia sie 
potrzeba inicjalizacji obiektu klasy E wartosciami 
pobranymi z bazy danych. Pomijajac szczegoly nasze 
zdanie SQL bedzie wygladalo nastepujaco

select cos-tam-cos-tam
from Tab_A, Tab_B, Tab_C, Tab_D, Tab_E
where warunek-laczacy-ze-soba-ww-relacje

Jak wiec wyraznie widac, aby otrzymac dane obiektu klasy
E nalezy uzyc "multiple join" laczacy 5 (!) relacji.
Przy odpowiednio duzej liczbie rekordow, jest to, biorac
pod uwage szybkosc, samobojstwo dla kazdej aplikacji.

Co bedzie, gdy nasza klasa zamiast 4 przodkow bedzie 
miala ich np. 10. Np.

A <- B <- C <- D <- E <- F <- G <- H <- I <- J <- K

i odpowiednio

Tab_A, Tab_B, Tab_C, Tab_D, Tab_E, Tab_F, Tab_G, Tab_H, 
Tab_I, Tab_J, Tab_K

Oto nasze zdanie SQL, ktorego nie radze uruchamiac

select cos-tam-cos-tam
from Tab_A, Tab_B, Tab_C, Tab_D, Tab_E, Tab_F, Tab_G, 
Tab_H,Tab_I, Tab_J, Tab_K
where warunek-laczacy-ze-soba-ww-relacje

Jaki sa z tego wszystkiego wnioski. Proponuje 
nastepujace:

1. Zasada "1 klasa 1 relacja" nie zawsze zdaje egzamin.
W takich sytuacjach nalezy sprobowac odwzorowania 
"N klas 1 relacja"
2. RBD + OO = same_klopoty


I to by bylo na tyle



Robert