[Java lista] optimalizálás

2011. Ápr. 12., K, 13:54:03 CEST

Üdv,

Akikkel én beszéltem, azok nagyon tesznek arra, hogy milyen költséggel
készíted el a szoftvert. Ez általában a fejlesztőcégnek cél.
Találkoztam olyanokkal is, akik a megrendelői oldalon lévő
legalacsonyabb szinten lévő emberek, akik csak azt hangsúlyozzák, hogy
csak tökéletesen kioptimalizált szoftvert lehet átvenni. És telepítés
után bújják a TOP SQL-eket.
Őket mivel szereled le? Azzal, hogy neked olcsóbb így megírni a
szoftvert, ti meg vegyetek alá majd vasat. Háát. Azt meg beadni a
megrendelőnek, hogy csak akkor kap optimalizált szoftvert, ha többet
költ, szerintem reménytelen. Ők ezt default-nak veszik.

Viczi

2011/4/12  <istvan.ketler at lhsystems.com>:
> 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
>>
>>
>