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?:-)