[Java lista] optimalizálás

2011. Ápr. 12., K, 13:40:39 CEST

Szia,

talán mert ezek a fickók még mindig abban a tévhitben élnek, hogy a szoftverfejlesztés az egész életciklus legfontosabb fázisa. Valójában a fejlesztés a teljes költségnek kisebb részét adja, és időben is a rövidebb, a nagyobb rész a karbantartás/üzemeltetés. Ez még akkor is igaz, ha a továbbfejlesztést is szoftverfejlesztésnek, nem pedig karbantartásnak tartjuk (ezen is lehet vitatkozni).

Ebből pedig pusztán üzleti alapon is az következik, hogy a karbantarthatóság a legfontosabb elvek között van. Ha sima hardver frissítéssel megoldható a felhasználó számára elfogadható sebesség/teljesítmény, akkor talán nem kéne nagy költséggel optimalizálni, ami utána ráadásul kevésbé lesz karbantartható, és valószínűleg kevésbé változástűrő is lesz.

István Ketler
Team Leader 
Lufthansa Systems Hungaria Kft. 
Airline Management Solutions 
- Schedule & Revenue Management 
- Business Intelligence & Database Solutions
Neumann János u. 1/e
1117 Budapest
Hungary 
Tel: +36 1 887-2815 
Fax: +36 1 887-2977
Mobile: +36 30 600-4936 
Room: Infopark E, Room LH1-31 
e-mail: istvan.ketler at lhsystems.com 
Internet: www.LHsystems.hu

Sitz der Gesellschaft / Corporate Headquarters: Lufthansa Systems Hungaria Kft, Budapest, Fövarosi Birosag 01-09-463417
Geschaeftsfuehrung / Management Board: Monika Houck

-----Original Message-----

From: István Viczián [mailto:viczian.istvan at gmail.com] 
Sent: Tuesday, April 12, 2011 1:25 PM
To: javalist at javagrund.hu
Cc: KETLER, ISTVAN
Subject: Re: [Java lista] JPA - Hogyan inzertáljak egy-több kapcsolatban lév? adatokat?

Üdv,

Oktatások során sok emberrel találkoztam (foleg üzemeltetok, vagy
üzemeltetés környékiek), akik tagadják ezt az elvet, és szerintük
ezért tart itt az informatika, ahol tart. Ezért vannak ilyen böhöm
alkalmazásszerverek, portálszerverek, stb. Ezért utálják a Java-t, és
minden hozzá kapcsolódó dolgot, hogy szép legyek ekorendszert. :)
Tuti a listán is van egy-ketto, aki vitatkozna ezzel, ha rossz napja van. :))))

Viczi

2011/4/12  <istvan.ketler at lhsystems.com>:
> Szia,
>
>
>
> miért kavartad volna meg?
>
>
>
> Az optimalizálás legfobb szabálya az, hogy soha ne optimalizálj. Ha mégis
> optimalizálni akarsz, elsoként környezetet vizsgálj (csak mert Commodore
> 64-en lassú, még lehet elfogadható sebességu egy OS 360-on, mondták az
> öregek). Ha még mindig lassú, mérj. Ha mértél, nézd meg hogy lehet-e
> algoritmust vagy technológiát váltani ott, ahol sok idot tölt. Ha nem lehet,
> vagy az nem elég, akkor kezdj el azon gondolkodni, hogy mit lenne célszeru
> optimalizálni. Kis lépésekben tedd, és mindegyik után mérj.
>
>
>
> Még ma is találkozom néha C-like nyelven fejlesztovel, aki szerint a ++i
> gyorsabb mint az i++...
>
> István Ketler
> Team Leader
>
> Lufthansa Systems Hungaria Kft.
> Airline Management Solutions
> - Schedule & Revenue Management
> - Business Intelligence & Database Solutions
> Neumann János u. 1/e
> 1117 Budapest
> Hungary
>
> Tel: +36 1 887-2815
> Fax: +36 1 887-2977
> Mobile: +36 30 600-4936
>
> Room: Infopark E, Room LH1-31
>
> e-mail: istvan.ketler at lhsystems.com
> Internet: www.LHsystems.hu
>
>
>
>
>
> Sitz der Gesellschaft / Corporate Headquarters: Lufthansa Systems Hungaria
> Kft, Budapest, Fövarosi Birosag 01-09-463417
> Geschaeftsfuehrung / Management Board: Monika Houck
>
> From: javalist-bounces at javagrund.hu [mailto:javalist-bounces at javagrund.hu]
> On Behalf Of Peter Verhas
> Sent: Tuesday, April 12, 2011 10:36 AM
> To: javalist at javagrund.hu
> Subject: Re: [Java lista] JPA - Hogyan inzertáljak egy-több kapcsolatban
> lév? adatokat?
>
>
>
> Szerintem Zsombornál van a pont.
>
>
>
> Mi történhet, amikor létrehozod az új Group csoportot, beállítod a
> GroupId-t, és utána a User objetkumot perzisztálod? A perzisztencia réteg
> nem feltétlenül ellenorzi, hogy van-e már ilyen GroupId a táblában, és nem
> olvassa fel (ezt akarod éppen performancia okok miatt elkerülni, és lehet,
> hogy sikerül is). Ellenben amikor legközelebb kell neked ez a Group
> objektum, akkor tudni fogja, hogy hoppá: ez már itt van a memóriában. És nem
> olvassa fel, hiszen toled már megkapta.
>
>
>
> Nem tudom pontosan, hogy mi történik a programodban, de a JPA objektum
> státuszokat kellene alaposan átolvasni és megérteni, ha tudni akarod, hogy
> mi történik, és miért null értékuek a mezok. Ha nem akarod ennyire
> részletesen megérteni, akkor (azon túl, hogy legközelebb más hibába fogsz
> belefutni a megértés hiánya miatt) kövesd Zsombor tanácsát.
>
>
>
> Amúgy egy általános javaslat, sok év tapasztalata alapján:
>
>
>
> Nem optimalizálunk a részletekben, amikor fejlesztünk. Ha hatékony kódot
> akarsz készíteni, akkor a következoket javaslom:
>
>
>
> - Tervezéskor hatékony algoritmust válassz. (nem implementációt, hanem
> algoritmust)
>
> - Kódolásnál írjál tiszta és szép kódot. Majd a fordító optimalizál amit
> tud, és ma már elég sokat tudnak.
>
> - Ha lassú, akkor profiler. Ne próbáld magad okosságból kitalálni, hogy hol
> lassú. Úgysem ott lesz lassú, ahol gondolod. Majd a profiler megmondja.
>
> - Azt a részt optimalizáld amelyik lassú.
>
> - Csak akkor optimalizálj ha üzletileg megéri, mert az optimalizált kód
> sokszor bonyolultabb, és ezért kevésbé karbantartható, késobb többe kerül.
>
>
>
> Attól félek ezzel megint megkavartam az állóvizet :-)
>
>
>
> --
> Verhás Péter
> peter at verhas.com
> +36(30)9306805
> skype: verhas
>
>
>
>
>
> On 2011.04.12., at 0:24, Zsombor wrote:
>
>
>
> 2011/4/11 Mariák Kálmán <sirkalmi at kalmiesemese.hu>
>
> Szervusztok!
>
> Egy-több kapcsolatban lévo adatok inzertálására van egy bevett
> eljárásom, amivel kapcsolatban problámák adódtak. Ezt az eljárást sehol
> nem olvastam, magam találtam ki, ezért lehet, hogy tök rosz az egész.
> Elsoként bemutatom az eljárásomat, aztán arra volnék kiváncsi, hogy ti
> hogyan oldjátok meg ezeket a dolgokat.
>
> Példa:
> Egy felhasználót hozzáadunk egy csoporthoz. A felhasználó és a csoport
> azonosítók paraméterbol jönnek. A felhasználót az azonosítója alapján
> elkérem az EntityManager-tol. Eddig semmi szokatlan. A csoport esetében
> viszont az entitásokat én példányosítom, amelynek csak az id
> tulajdonságát állítom be. Ez pont elég ahoz, hogy ez alapján a
> kapcsolatokat megfeleloen le tudja tárolni az adatbázisban.
>
> User user = em.find(User.class, userId);
> Set<Group> groups = new HashSet<Group>();
> Group group = new Group();
> group.setId(groupId);
> user.setGroups(groups);
> em.merge(user);
>
> Ezt anno azért találtam így ki, hogy takarékoskodjak az eroforrásokkal,
> és hogy ne kelljen értelmetlenül az adatbázishoz fordulni, mikor eleve
> minden információ rendelkezésre áll amit le kell tárolni. Ugyanakkor
> kényelmes is amit az alábbi példában szemléltetek:
>
> A User entitásnál maradva, annak van egy CompanyType típusú
> tulajdonsága. Ha a company type szintén paraméterbol jön akkor azt a
> User entitás setCompanyTypeId metódussal állítom be, amiben
> példányosítok egy CompanyType objektumot, majd meghívom vele a
> setCompanyType metódust, ezzel beállítva a kapcsolatot.
>
> Az alap settter metódus.
> public void setCompanyType(CompanyType companyType) {
>  this.companyType = companyType;
> }
>
> A "kényelmi" kiegészíto setter metódus
> public void setCompanyTypeId(Long companyTypeId) {
>  CompanyType companyType = new CompanyType();
>  companyType.setId(companyTypeId);
>  setCompanyType(companyType);
> }
>
> A paraméterek rendszerint JSON fromátumban érkeznek, amit a Jackson nevu
> eszköz mappel rá az entitásokra. A paraméterek nevei alapján
> automatikusan meghívja a setter metódusokat. Pl a fenti példában, ha a
> JSON-ban van egy companyTypeId paraméter akkor a Jackson meghívja a
> setCompanyTypeId metódust.
>
> A probláma ezzel az egésszel az, hogy persist vagy merge után a program
> egy egészen más pontján, pl egy JPQL lekérdezés során visszaadott
> eredményben, ha szerepelnek ezek az entitások melyek, így én álltalam
> lettek példányosítva, akkor ezeknek a tulajdonsági mind null-ok lesznek
> az id-t leszámítva. Ezen csak egy webapp restart segít, mikor
> valószínuleg kiürül az Entit Manager -ben a cache és újból beolvas
> mindent.
>
> Egyelore két megoldást látok, vagy felhagyok ezzel a megoldással és
> mindig minden entitást id alapján elkérek az EM-tol és ezeket állítom
> be, vagy lekérdezésekkor ellenorzöm, hogy adott tulajdonság null-e és,
> ha igen akkor meghívom az adott entitásra az EM update metódusát, amely
> frissíti az adatbázisból az összes tulajdonságát.
>
> Mind a két megoldás macera, nem tetszik. Mitévo legyek?
>
> Köszi a válaszokat!
>
> Mariák Kálmán
> sirkalmi
>
> Egy enitityManager.find(cls, id) hivás nem feltétlenül jelent adatbázis
> lekérdezést, és használd azt, ne próbáld meg megeroszakolni a JPA
> implementációt ilyen kis trükkökkel.
>
> üdv
>  Zs
>
>
> _______________________________________________
> Javalist mailing list
> Javalist at javagrund.hu
> http://javagrund.hu/mailman/listinfo/javalist
>
>
>
> _______________________________________________
> Javalist mailing list
> Javalist at javagrund.hu
> http://javagrund.hu/mailman/listinfo/javalist
>
>