Hirdetés
- Android alkalmazások - szoftver kibeszélő topik
- iPhone topik
- Szívós, szép és kitartó az új OnePlus óra
- Amazfit Bip 6 - jót olcsón
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Samsung Galaxy A56 - megbízható középszerűség
- Baseus Inspire XH1 – nyomokban Bose-t tartalmaz
- Félmillió felett a kiszállított Xiaomi autók száma
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Apple Watch Sport - ez is csak egy okosóra
Új hozzászólás Aktív témák
-
-
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. -
-
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.
-
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.
-
-
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
- Keresünk iPhone 12/ 12 Mini/ 12 Pro/12 Pro Max
- 184 - Lenovo Legion Pro 7 (16IAX10H) - Intel Core U9 275HX, RTX 5090 (FOGLALVA)
- HP Thunderbolt 4 kábel
- BESZÁMÍTÁS! MSI B760 i7 13700K 32GB DDR4 2TB SSD RTX 4080 16GB be quiet! 500DX Seasonic 750W
- Tablet felvásárlás!! Apple iPad, iPad Mini, iPad Air, iPad Pro
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest