O vnitřní reprezentaci se nebavíme, nehledě k tomu, že vnitřní reprezentace seznamu obvykle ani indexy nemají. Indexy u seznamu ani nejsou potřebné, resp. jejich používání porušuje zapouzdření.
Naopak, pole je pro implementaci seznamu výhodné, koneckonců když se implementace přesune níže do primitiv, stejně z toho nejspíš vyjde pole.
Když je to vnitřní reprezentace, tak se indexy ven nedostanou.
U Lispu je to skutečně seznam, Java má LinkedList. Ovšem vnitřní reprezentace kolekcí nás v aplikaci nezajímá. Prostě jen vybereme tu výhodnější.
Mezi OOP a RDB musí být vložena mezivrstva. Ta může být v aplikaci nebo v databázi, případně vhodně rozdělena mezi ně tak, aby bylo co nejjednodušší a přitom robustní API. Pro umístění v databázi hovoří zejména fakt, že už má svou cache, takže není třeba dělat v OOP nějaké náhražky.
Ona mezivrstva s mapovačem musí být stejně v aplikaci, protože jediná z těch 2 umí manipulovat s objekty i n-ticemi, pro RDB jsou objekty jaksi cizí, takže nemá jak ony objekty poskytovat (třeba v JSONech nebo já nevím v čem).
Vzhledem k tomu, že RDB umí poskytovat objekty...
Adaptivní mechanismus je jednoduchý: Aplikace se nespoléhá na to, že dostane co chce, ale analyzuje výsledek z RDB a ten zpracuje. Vazba je tedy adaptivní, opírá se o jednoduché a neměnné API.
Takže tam už nějaké mapování je, není to jednoduchá kopie 1:1.
Mapování přece nepopírám. Jen je tak jednoduché, že skoro nestojí za řeč. Mapper ty databázové sloupce ani nepotřebuje znát.
Každý element stromu je relací. Strom je kolekcí, tedy i objektem.
Supr, a teď mi popište, jak se takový strom prochází.
Rekurzí.
241 Odpovědí
33297 Zhlédnutí