Posted By: Jovo () on 'CZprogram' Title: Ad: extends Date: Sun Jan 30 18:48:38 2005 Ahoj. Zrovna tohle jsem resil v poslednich dvou mesicich. V db je to priblizne tak, jak to napsal Roumen. Pak se to da resit vice zpusoby: 1] na kazdy objekt z databaze trida a par objektu, ktere to skladaji. Vyhoda: da se to vsechno oddedit z tri trid: model, mapovani model->databaze, kompozice vice objektu do jednoho. Nevyhoda: pokud to chcete mit 100%ne chodive a mate data ve vice databazich (muj pripad), pak to bude kur**sky pomale. Typicky se dojde k tomu, ze se nacte kolekce a ke kazdemu objektu v kolekci to poleze do databaze a bude delat SELECT ... FROM detail... Nebo si implementujete mechanismus, ktery vam bude k SELECTum pripojovat i sloupecky, tabulky a vazby na detaily a tim vam vyrobi jeden obri SELECT. Pak pri prochazeni [Result|Row]Setu budete muset osetrit i nacitani dat pro detaily, ale to neni zase takovy problem. Pokud se zmeni struktura dat (sloupecky), staci jen prepsat tu cast [kodu|properties], kde je definice sloupcu. 2] Vyserete se na vyse popsane a vyresite to pres VIEW:-) Vyhoda je, ze se to vsechno chova naprosto transparentne a v Jave jen dedite tridy. Nevyhody: Vase databaze musi podporovat i INSERT, UPDATE a DELETE na VIEW. Vetsinou to neni problem, ale jak jsem slysel, nektere databaze toto nepodporuji. Z hlavy vim, ze DB2 v7 to podporuje. Dalsi nevyhoda: musite si nad danym VIEW napsat triggery pro I/U/D - napr. trigger pro INSERT vezme data a da INSERT do Vehicle a INSERT do Car kdyz delame INSERT do CREATE VIEW WholeCar AS SELECT a.*, b.* FROM Vehicle a, Car b WHERE a.id = b.parent_id A nakonec jedna podstatna nevyhoda: Kazda databaze ma praci s VIEW a triggery jinak, takze pokud budete vyvijet neco, co by melo byt cross-platform, tak skoncite u toho, ze budete mit pro kazdou databazi jinou sablonu pro VIEW a triggery. Potencialni otazky take vyplvaji z indexu a constraintu a pokud mate VIEW pracujici s jinym VIEW a tak dal, tak vas muze zajimat i data clashing (databaze ma 10 MB dat, ale i s indexy ma pul giga). Pokud se zmeni struktura databaze, musite nejen menit vasi Java vrstvu, ale i definici VIEW a triggeru. Co je lepsi? Ja hlasuju jednoznacne pro (2). Je to mnohem rychlejsi, veskerou logiku skladani dat za vas resi databaze, mene toho naprogramujete ( -> mene chyb) a udelate to rychleji. Jovo. PS: hadejte, jestli na tom, na cem delam mame povolene VIEW?:-)