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

• #4455 Szmeby tag MrSealRD #4451

  Új Válasz 2020-03-10 14:17:53 #4455

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Szmeby

  tag

  válasz MrSealRD #4451 üzenetére

  "Inkább felhasználói oldalról volt ez vizsgálva. Hogy ne kelljen sok képernyőn keresztül kiigazodnia a user-nek, hogy karbantartsa ezeket az adatokat. Így egy képernyőn el tudja intézni."

  Mi köze a UI-nak a DB reprezentációhoz?

• #4454 nyunyu félisten MrSealRD #4451

  Új Válasz 2020-03-10 11:23:56 #4454

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  nyunyu

  félisten

  válasz MrSealRD #4451 üzenetére

  Normalizálásnak megvan a maga helye és az ideje, de ez az eset nem tűnik annak.
  Mostanában már nem annyira a tárhely (memória, vinyó, szalag...) a szűk kapacitás, mint tizenévekkel korábban, így már nem feltétlenül érdemes a normalizációval megspórolható helyre gyúrni.

  Adattárházaknál például bevett szokás a csillag séma, amikor egy nagyon széles, sokmillió soros ténytáblához joinolnak sok kicsi dimenziót, viszont a dimenziótáblák tartalmát nem nagyon szokták normalizálni, hogy minél kevesebb joinnal gyorsabban lekérdezhető legyen a nagy mennyiségű adat.
  Vannak olyan mondások is, hogy a dimenziókat nem ártana normalizálni, azt hívják hópehely sémának, de az általában ront a lekérdezések, adattranszformációk sebességén.

  Előző projektünkből kiindulva az sem ideális, amikor tizen-huszon, alig pár rekordot tartalmazó paramétertáblát kell kerülgetned, hogy mi az amit a következő shipmentbe bele kell tenned, és mi az amit nem szabad.
  Olyankor valami mindig kimarad, vagy éppen felülírod az éles beállításokat egy alsóbb környezetre érvényes teszt beállítással.
  Ráadásul fél évvel később az üzemeltetési doksi írásakor már nem is emlékeztem arra, hogy kollégák melyiket mire használták, sokat úgy kellett kitúrni a kódból, amikor az üzemeltetők rákérdeztek valami egyedi beállítási lehetőségre.

  Azon a projekten a fontosabb paraméterek állítására például az Üzlet kért egy képernyőt, ahol Excelben letöltheti a fontosabb paramétertáblák tartalmát, majd szerkesztés után visszatölthesse.
  Azokat a táblák tartalmát például tilos volt dumpként a shipmentbe adni, nehogy felülírjuk a felhasználók beállításait.
  Ha új sorok kellettek, akkor azokat élesítéskor insertekkel kellett beszúrni.

• #4452 Ferfiu tag MrSealRD #4451

  Új Válasz 2020-03-10 10:39:43 #4452

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Ferfiu

  tag

  válasz MrSealRD #4451 üzenetére

  Én azt javaslom, hogy tedd le a voksodat a közös vagy a külön táblák mellett. Nincs lényegi különbség gyorsaságban, a fejlesztők/üzemeltetők életét könnyíted meg, ha egységes, és nem keveredik a két hozzáállás egy adatbázison belül.

• #4450 nyunyu félisten MrSealRD #4445

  Új Válasz 2020-03-09 23:04:58 #4450

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  nyunyu

  félisten

  válasz MrSealRD #4445 üzenetére

  Ha az a cél, hogy enumokat tárolj, akkor egy szótártábla elég, amiben van enum_neve, sorszám, érték.
  (Aztán utána lehet hitvitákat folytatni, hogy nullától vagy egytől indexeljünk, lásd java vs sql)

  Ha viszont Hibernateet akarsz használni DB kezelésre, akkor jól gondold meg, hogy mire vállalkozol, mert az arra tökéletesen alkalmatlan.

  Előző projekten alapvetően Oracle DBben fejlesztettünk egy üzleti alkalmazást, afölé lett Javaban írt frontend-backend téve, aztán az eredeti elképzelés az volt, hogy a Hibernate közvetíti az DBben lévő adatokat a Java GUI felé.
  Aha, iszonyúan erőforráspazarló, nem gyors, de legalább az összes adatműveletnél lockolja az összes érintett táblát, tábla szinten.

  Gyakorlatban totálisan alkalmatlannak bizonyult többfelhasználós célokra, mert folyamatosan homokórázott a rendszer a Hibernate hülyeségei miatt lockolt táblák miatt.
  Végül az össze 3 táblából összejoinolok egy táblázatot kérdésre az lett a válasz, hogy a GUI meghív egy tárolt eljárást, ami elvégzi a joint, és az eredményt visszaadja egy kurzorban, aztán annak a tartalmát húzták be a kliens oldalon tovább szűrhető gridbe.
  Vagy natív query.

  A másik nagy kedvencem a késleltetett írás témája.

  Felhasználó képernyőn kitölt egy táblázatot, amit egy az egyben a Hibernate ment egy DB táblába.
  Elmélet az, hogy a táblázat soráról elvéve a fókuszt azonnal menti a módosult sort a DBbe.
  Gyakorlatban? Ha a felhasználó rábökött a Tovább gombra, ami meghívott valami tároltat, ami a frissen töltött táblát használta, akkor az esetek 20%-ában nem volt elmentve az utoljára szerkesztett sor, és a DBben implementált logika emiatt hülyeséget csinált.
  Én meg nyomozhattam, hogy mi a francért van jó adat a forrástáblában, az adattranszformáció végén meg rossz. (Hibernate végül mégiscsak elmentette, miután a DB már felhasználta a rossz adatot...)
  Végeredmény? Javas kollégákkal veszekedtem pár napot, hogy a DB tárolt hívása előtt MENTSÉK el a táblát.

  Ez vajon megoldotta a problémát?
  A fenéket, méréseim szerint még mindig 3% adathibát okoz, hogy a SaveAndFlush() sem ment azonnal.
  Utolsó ötletük a javas kollégáknak a probléma megoldására a Thread.Sleep(500) beiktatása volt a SlaveAndFlush() és a DB tárolt hívás közé...
  Mivel az ilyen hókuszpókuszokban nem bízom, inkább beraktam egy összehasonlítást a transzformáció végére, hogy ha inkonzisztenciát lát, azonnal fusson újra az időközben mentett adatokra.

  Harmadik agybaj meg az volt, hogy a Hibernate konkrétan lebénul attól, ha olyan táblába kell sorokat beszúrnia, ahol a tábla egyedi kulcsát képező szekvencia egyesével lépked. (ami ugye a DB default beállítás...)
  Javas kollégák magyaráztak valami marhaságot arról, hogy a Hibernate húszasával becacheli előre a leendő ID értékeket, így a szekvencia lépésközét ennél nagyobbra kell állítani, hogy ne akadjon össze a DBvel egy-egy insertkor.

  Szóval csak óvatosan a Hibernatetel, mert attól erősen csökken a savassága a DBnek.

• #4449 whYz őstag MrSealRD #4447

  Új Válasz 2020-03-09 22:32:21 #4449

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  whYz

  őstag

  válasz MrSealRD #4447 üzenetére

  A diagramod teljesen okesnak tunik, sot en meg a player tablat tovabb is bontanam egy contracts tablara.

  Szerintem ez a javaslat olyan olvasszunk ossze ket tablat, hogy kevesebb tablank legyen otletnek tunik, mindenfele logika nelkul.

  Ket teljesen kulon dolgot ne akarj 1 tablaba eroszakolni, mert nem ersz el vele semmit. Ha 1 tabla csak egy egyszeru akar statikus adatot tarol 2 darab oszloppal akkor abban nincs semmi rossz. Ha a ContractTypes es a Level egyutt letezik, osszetartozik akkor mehet egy tablaba, ha viszont vagy egyik vagy masik, akkor legyenek kulon.

  Raadasul TYPE + ID kombinacioval nem tudsz hatekony composite primary keyt alkotni, mivel az ID folyamatosan no, ergo mindig egyedi lesz, gyakorlatilag ugyanaz mintha csak az ID lenne PK.

• #4448 bambano titán MrSealRD #4445

  Új Válasz 2020-03-09 22:02:29 #4448

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  bambano

  titán

  válasz MrSealRD #4445 üzenetére

  első ránézésre nem látok kivetnivalót az ötletben.
  nem sokkal lesz bonyolultabb az az űrlap, ahol a feleletválasztót használod, viszont nem kell soktíz crud-ot leprogramozni a törzs karbantartáshoz.
  szerintem érdemes kipróbálni.

• #4446 whYz őstag MrSealRD #4445

  Új Válasz 2020-03-09 20:58:04 #4446

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  whYz

  őstag

  válasz MrSealRD #4445 üzenetére

  Inkabb itt valaszolok mert ez sql.

  Normalizacio, normalizacio, normalizacio. Nem tudom elegszer mondani. Attol, hogy 1 tablaba pakolod az osszes adatod nem lesz gyorsabb a lekerdezes, ha jol van megdesignolva akkor akar rakas joint is pakolhatsz bele, gyors lesz.

  Ha mutatsz egy konkret peldat, akar uml diagrammot, akkor tobbet tudunk segiteni.

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