Zdravim,
mozna je muj prispevek offtopic, ale rad bych upozornil na jednu dulezitou
vec, a sice ze dedicnost neni jedinym zpusobem typovani.
Zde bych velice zvazoval, zda nemit jednu tabulku Vozidlo, vedle ni ciselnik
TypVozidla a na nej se z Vozidla odkazovat FKckem. Analogicky i v Javovem
objektovem navrhu - kompozice, ne dedicnost. Resit vsechno dedicnosti je
mor, jak v cistych objektech, tim spise pak v objektech mapovanych pres ORM.
[opravdu offtopic: Mor je to velice rozsireny, zrejme diky pojeti ucebnic
OOP, ktere kazdemu zacatecnikovi vsugeruji, ze dedicnost je "to maso"].
Podle mych zkusenosti to s dedicnosti v ORM nakonec dopada tak, ze jako
smysluplne entity se jevi ty, ktere jsou koncove listy stromu dedicnosti,
jejich predci jsou "abstraktni" - v tom smyslu, ze napr. nema cenu je
zakladat samostatne. Priklad: kdyz mate od Vozidlo oddedene OsobniAuto,
NakladniAuto, Traktor, proc budete zakladat primo instanci Vozidla? Abyste
tam schoval vse, co se neni ani osobak, ani nakladak a ani traktor? To si
zakladate na pekny chlivek... V tomto smyslu je, rekl bych, entita Vozidlo
abstraktni, pak je otazka, k cemu potrebujete mit jeji tabulku v db atd...
Typovani pomoci odkazu na vyctovy typ je mnohem praktictejsi.
Roman
----- Original Message -----
From: "Ondřej Kvasnovský" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, December 14, 2006 12:29 PM
Subject: Re: ORM vs OBD
Makub wrote:
Ondřej Kvasnovský wrote:
> Ahoj,
> ja v tom teda problem nevidim... myslim ty vozidla. prece si vytvoris
> napr.:
hlavni objekt Vozidlo a od neho budes dedit vsechny ostatni vozidla
(traktor,
vlak, osobni automobil... ).
Na strane objektoveho jazyka Java samozrejme problem s objekty neni :-))
> Jak to namapujes do relacni databaze je uz plne na tobe.
No ale tady je prave ten problem, ze to spravne namapovat nejde,
protoze mezi objekty a relacemi zeje filozoficka propast :-)
> Samozdrejme to muzes narvat do jedne tabulky, ale tim ti vznikne hodne
> volnych
mist a hodne velkaaa tabulka. Proste peklo... Ani se tento zpusob nikde
nedoporucuje....
To jsem psal.
> Nebo to muzes namapovat do tolika tabulek kolik je potomku tridy
> vozidlo, to
je jeste lepsi reseni. Akorat se tam bude mit duplicitni sloupce....
Cimz ztratim moznost delat SQL dotazy na vsechna vozidla, nejdriv se musim
podle typu vozidla vybrat tabulku, a pak teprve udelat dotaz.
Krome toho co kdyz mi casem pribude dalsi typ vozidla ?
To bych pak musel pridelat dalsi tabulku, a pritom je to
jenom potomek Vozidla. Skutecna objektova databaze mi
by to mela usnadnit.
Jo jo, mas pravdu. Neni to dobry zpusob, ale slo by to :) ikdyz nechtel bych
byt u toho az nekdo bude chtit delat update a pridavat dalsi tabulku :)
Slysel jsem, ze PostgreSQL ma objektove rozsireni,
ktere umi tabulky dedit, takze pak muzu snadno delat
dotazy na vsechna vozidla i na konkretni typy.
Ale neni to standard, a pri pridani dalsiho
potomka porad musim pridat dalsi tabulku.
V PostgreSQL jsem narazil na jednu zvlastnost. Kdyz jsem poprve delal s
Hibernate, tak jsem ji pripojoval na PostgreSQL. Mel jsem tam chyby, ktere
vzplynuly z objektoveho mysleni. PostgreSQL to ale pochopil a nestezoval si.
Kdezto kdyz jsem to spustil na MySql tak to nejelo, sice se to v poradku
namapovalo, ale to bylo vsechno. :) Coz me trochu zmatlo, myslel jsem ze
kdyz uz to jede na jedne databazi tak to musi jet na vsech databazich co
hibernate podporuje... ale ono ne. ;) Pak jsem zjistil ze PostgreSQL je tak
trochu objektove orientovane a bylo to jasne.
> A nebo udelas jednu hlavni tabulku Vozidlo, v ktere budou reference mezi
jejimy potomky. Ja osobne bych to udelal timto zpusobem.
Tohle jsem nepochopil. Jak reference mezi potomky ?
Mozna jsem to napsal ne uplne spravne, myslel jsem reference mezi rodicem a
potomkem. Kdezto v rodicovske tabulce by byli vsechny atributy (sloupce),
ktere by potomci dedili. Pak by byly tabulky potomku a v nich by byla uz jim
specificka data (atributy, sloupce.. ).
Myslim ze je to doporuceny postup jak namapovat databazi do relacni db.
Pak je samozrejme ctvrte reseni, ze budu mit jednu tabulku VOZIDLA
a druhou tabulku VLASTNOSTI_VOZIDEL, ktera bude mit sloupce
(VOZIDLO_ID int, VLASTNOST varchar, HODNOTA varchar)
kde VOZIDLO_ID je foreign key do tabulky vozidel,
do sloupce VLASTNOST budu strkat nazvy vlastnosti a
do HODNOTA jejich hodnoty, cimz budu simulovat promenny pocet sloupcu.
Ale je to dost neefektivni.
Tak to se mi moc nelibi... ale taky moznost :)
Cache pry dela interne neco takoveho, ale efektivne.
Asi to Cache zkusim... Bylo by dobre, kdyby nekdo dal nejaky osvedseny a
100% nabuseny link na tutorialek :)
> Takze bych to jako hlavni problem mezi OBD a ORM nevidel... proste tam
> musi
byt neco asi jineho. Nebo Cache, coz by mela prej byt ODB, je "jen" pseudo
objektova databaze. Ma v tom nekdo jasno? Jesti jo tak to rad "uslysim".
:)
Jasno v tom nemam, ale ten priklad s vozidly mam z jedne knizky
o databazich, kde vysvetlovali rozdil mezi relacnimi,
relacne-objektovymi a objektovymi databazemi.
A jestli to fakt dela... tak je to mazec. Zase by bylo o starost min. Ikdyz
stejne, ani principialne, mi neni jasne jak vi ktere atributy chci ulozit.
Stejne bych to nejak musel na mapovat, ne? Prece nebudu ukladat cele
objekty... i s tim co nechci aby bylo persistentni... Snad ze by se to
serializovalo...a urcovalo by se u atributu jestli jsou transient nebo ne...
Makub
Ondra.
