Enterprise Java, Jpa, Oracle Object
2008-10-08T09:17:19+02:00
2008-10-09T08:52:51+02:00
2022-07-01T04:51:11+02:00
  • A JPA2.0 többet tud már ebből, de általános dolog, hogy a könnyű DB csere és a rugalmasság oltárán feláldozzák a DB tudását, és inkább vastagabb hardver kerül az üzleti logika alá, minthogy vendor lock legyen a DB oldaláról.


    Ezt valhogy en is igy latom. Csak abban nem vagyok biztos, hogy jo e ha pl. egy nagyon jo adatbazis szerverrol attevodik a terheles az alkalmazas szerverre. Nem az lenne a cel, hogy probaljuk elosztani a terhelest a retegek kozott is? Mert igy csak atkerul. Mi a helyzet ha a terhelset is szeretnem elosztani a retegek kozott? Azaz amit a db tud jobban, az oda keruljon. Mik a korlatai az Enterprise-nak es JPA-nak? Mikor eri meg azon gondolkozni, hogy itt meg sem ezeket hasznaljuk?

    Laci
    Mutasd a teljes hozzászólást!
  • A masik kerdesem ehhez a temahoz kapcsolodoan a JPA hasznalata. Hibernate-et hasznaltam eddig es tetszett. Viszont ezzel kapcsolatban az lenne a kedesem, h nagyobb adabatbazisnal/adatmennyisegnel erdemes e hasznalni? Egyaltalan mik a korlatai? Az optimalis teljesitmenyhez cachelnie kell. Jo e az nekem, ha az alkalmazasszerver memoriajat is zabaltatom? Ugyanakkor az adatbazisszerver is intenziven cachel. A hibernate azt mondja, hogy az uzleti logikat gyorsan csinaljuk meg, utana meg majd szepen belojuk a teljesitmenyt(az ugy is kevesebb idoraforditas).


    Nézz meg más JPA providereket is. Például Oracle TopLink Essentials, vagy a nagy TopLink (ami EclipseLink néven nyílt forrású lett), esetleg az OpenJPA is érdekes lehet. Aztán ezekhez vagy van cache, vagy nincs... ha van, akkor általában segít, ha nem erővel csinálod, hanem csak azt, amiről tudod, hogy sokszor fogod kérdezni és ritkán módosul, de nem sok adat. Mindent nem éri meg gyorstárba tenni... :)

    Mi a helyzet a db-specifikus dolgokkal? Korabban hasznaltunk Oracle specifikus dolgokat: Oracle object, Nested table. Ezekre peldaul nem talatam megoldast hibernate alatt, csak jdbc-vel tudtam kezelni.


    A JPA2.0 többet tud már ebből, de általános dolog, hogy a könnyű DB csere és a rugalmasság oltárán feláldozzák a DB tudását, és inkább vastagabb hardver kerül az üzleti logika alá, minthogy vendor lock legyen a DB oldaláról.
    --
    Sorry - this page has moved
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    Kivancsi lennek, h mik a tapasztalatotok a cimben megjelolt temaban.
    1, Ebben a szemleletmodban az alkalmazas vegez minden uzleti folyamatot, a jogosultsagkezelest is. Mit lehet tenni olyan esetben mikor az adatok vedelme fontos es pl. adatbazis szinten is kellene korlatozni, hogy ki mihez ferhet hozza (pl. tabla, oszlop szinten).
    2, A masik kerdesem ehhez a temahoz kapcsolodoan a JPA hasznalata. Hibernate-et hasznaltam eddig es tetszett. Viszont ezzel kapcsolatban az lenne a kedesem, h nagyobb adabatbazisnal/adatmennyisegnel erdemes e hasznalni? Egyaltalan mik a korlatai? Az optimalis teljesitmenyhez cachelnie kell. Jo e az nekem, ha az alkalmazasszerver memoriajat is zabaltatom? Ugyanakkor az adatbazisszerver is intenziven cachel. A hibernate azt mondja, hogy az uzleti logikat gyorsan csinaljuk meg, utana meg majd szepen belojuk a teljesitmenyt(az ugy is kevesebb idoraforditas).
    3, Mi a helyzet a db-specifikus dolgokkal? Korabban hasznaltunk Oracle specifikus dolgokat: Oracle object, Nested table. Ezekre peldaul nem talatam megoldast hibernate alatt, csak jdbc-vel tudtam kezelni. Viszont a mi alkalmazasunkban jol jott ezek hasznalata.
    4, Mikor van egy nagyon jo adatbazisszerver (pl. Oracle). Miert jo az nekem, hogy ott van egy eros db szerver es csak adatokat tarolok benne, holott az uzelti logika egy reszet is kezelhetne (pl. Nested table, triggerek hasznalata stb.). Tervezeskor mi az amit figyelembe vesztek, hogy mit kezeljen a db es mit az alkalmazas?

    Koszi!

    Laci
    Mutasd a teljes hozzászólást!
abcd