Keresés

Új hozzászólás Aktív témák

  • Mukorka
    addikt

    List és arraylistet példányosítok belőle,de az OrderColumn megoldotta.

    Szerintem nem jó pattern ez a hozzáadási sorrend. Db oldalról ha riportot kéne csinálni akkor is úgy keresenéd le az első 3 helyezettet hogy hányadik sorban vannak a táblában? Mi van ha később több infó is kell egy helyezettről, nem csak az hogy ki volt? Teszem azt, idő, pont stb. Sztem ez egy külön helyezés táblát érdemelne. Illetve írtad is hogy végeredmény alapján pakolod be, ezek szerint lenne mi alapján összekötnöd is őket...

  • floatr
    veterán

    Írok egy példát, remélem érthető lesz.
    manytomany listához adok hozzá meglévő rekordokat.
    Pl: van 3db A tipusu rekordom 1-2-3 id-vel. Én ezt a B tipusu manytomany listába belerakom 2-3-1 sorrendbe és mikor később lekérem, akkor a listában az objektumok már az 1-2-3 szerint lesznek. Az összekapcsoló táblázatban viszont jó sorrendbe mutatja őket, csak mikor lekérem a listát, az nem felel meg annak a sorrendnek. Ugye van egy táblázatom ahol mutatja a kapcsolatokat, jelen esetbe, id-k alapján 1-2, 1-3, 1-1, feltéve hogy az 1-es kulcsú B entity listájához csapom hozzá ezeket az adatokat.
    Azért szeretném így megoldani, mert a 2-es kulcsú B entity listájába ugyanezt a 3 A tipusut akarom csak pl 1-3-2 sorrendbe és így tovább. Ugyanazok a játékosok vesznek részt más versenyeken és így szeretném megvalósítani a helyezéseket, lehet nem így kéne, de még csak most kezdtem el ezt tanulni.

    Milyen collection-t használsz a kapcsolat leírására a bean-ben?

  • Szmeby
    tag

    Köszi szépen, működik, nem is értem, hogy nem akadtam rá erre.
    Esetleg tudnál tippet adni, hogy tudnám jobban megvalósítani az elképzelésemet?
    Leegyszerűsítve jelenleg vannak felhasználok, akiknek lehetnek versenyezői és a verseny végeredmény alapján kapnak pontokat a felhasználok. Azért gondoltam így, mert azok a versenyzők akikből válogathatnak a felhasználók, az mindenki számára ugyanaz az n db. Gondoltam, ha létrehozok egy listát a verseny entitásban, amibe majd belepakolom a versenyzőket végeredmény alapján, akkor nem hozok létre semmi extra adatot és így elkerülhetem az adatok többszörös tárolását fölöslegesen.

    Hogy mi a jó, az relatív. Neked kell tudnod, hogy mire van szükséged.

    Ha jól értem, akkor azt az információt, ami a versenyzők helyezését reprezentálja, a listában lévő elemek sorrendje határozza meg.
    Amíg egyedül dolgozol a projekten, nem jelenthet problémát, mert mindent tudsz a programról. Amikor többen is bekapcsolódnak a fejlesztésbe, akkor előtérbe kerül az érthetőség, átláthatóság. Ha úgy gondolod, hogy aki ránéz a kódra és egyből leesik neki, hogy a helyezés a listaelemek sorrendje, akkor nem lesz probléma az értelmezéssel. Amennyiben nem egyértelmű, akkor ennek az információnak láthatóbb helyen kell lennie, pl. egy objektum egy mezőjében.

    A jelenlegi helyzetben ezt redundánsnak gondolod, de korábban felvetették, hogy adatbázistól függ, hogy mennyire megbízható a sorrend. A Hibernate alatt pedig semmi perc alatt cserélhető az adatbázis implementáció. De akár olyan galádság is megtörténhet, hogy valaki a jól bejáratott List-et Set-re cseréli, mert nem jut eszébe, hogy a sorrend is fontos. Persze a te esetedben ettől nemigen kell tartani. Viszont az előbbi szituációkban nem jelent redundanciát a helyezés dedikált helyen való eltárolása.

    Egy másik érdekes dolog, hogy a listaelemek sorrendjére való építkezés nem támogatja a holtverseny fogalmát. Valószínűleg a véletlen dönt arról, hogy holtverseny esetén ki sorolódik előrébb. Ez tesztelhetőség szempontjából nem feltétlenül ideális állapot. Tesztelhető ugyan, de a véletlen sorrend miatt nehézkes.

    Persze ha fontos számodra teszemazt a memóriaméret, a redundancia alacsonyan tartása, és biztosan tudod, hogy a fent említett anomáliák (vagy hasonlók) sohasem történhetnek meg, akkor nem kell dedikált mezőt készíteni a helyezésnek. Felesleges.

  • Senhi
    aktív tag

    Írok egy példát, remélem érthető lesz.
    manytomany listához adok hozzá meglévő rekordokat.
    Pl: van 3db A tipusu rekordom 1-2-3 id-vel. Én ezt a B tipusu manytomany listába belerakom 2-3-1 sorrendbe és mikor később lekérem, akkor a listában az objektumok már az 1-2-3 szerint lesznek. Az összekapcsoló táblázatban viszont jó sorrendbe mutatja őket, csak mikor lekérem a listát, az nem felel meg annak a sorrendnek. Ugye van egy táblázatom ahol mutatja a kapcsolatokat, jelen esetbe, id-k alapján 1-2, 1-3, 1-1, feltéve hogy az 1-es kulcsú B entity listájához csapom hozzá ezeket az adatokat.
    Azért szeretném így megoldani, mert a 2-es kulcsú B entity listájába ugyanezt a 3 A tipusut akarom csak pl 1-3-2 sorrendbe és így tovább. Ugyanazok a játékosok vesznek részt más versenyeken és így szeretném megvalósítani a helyezéseket, lehet nem így kéne, de még csak most kezdtem el ezt tanulni.

    Egy kicsit is komolyabb adatbázis esetén nem szabad arra játszani, hogy (rendezés nélkül) az adatok mindig ugyanabban (pl. berakás) sorrendjében kerülnek visszaadásra. Van egy eredeti sorrendjük, de ha a db úgy gondolja, hogy egy lekérdezéshez egy másik sorrend hatékonyabb akkor azt használja.

    Ettől függetlenül problémádat szerintem megoldja az @OrderColumn annotáció, amit arra a listára kell rárakni amelynek meg akarod tartani a sorrendjét.

  • floatr
    veterán

    Ha a hibernate/DB generál ID-t, akkor az automatikusan inkrementált érték lesz. Magyarán ha ID alapján rendezed, akkor beszúrás dátuma alapján is rendezted. Nincsen automatikus rendezés tudtommal, egyszerűen csak ez a természetes sorrend.

  • bucsupeti
    senior tag

    Sziasztok

    Azt belehet állítani h az entity osztályomban a manytomany listára ne történjen semmiféle rendezés?
    Nincs berakva az OrderBy annotáció, de így rendezi kulcs alapján. Nem találtam neten sehol, hogy lehetne kikapcsolni a rendezést. Fontos lenne, mert úgy szeretném megkapni az adatokat amilyen sorrendben belepakoltam és nem akarok új adattagot létrehozni csak az automatikus rendezés miatt. JPA/Hibernate annotáciokat használok.

    az objektum azonosító id az nem autoincrement?

Új hozzászólás Aktív témák