Hirdetés
- Luck Dragon: Asszociációs játék. :)
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- balojazz: Szódakészítés üzembiztosan és olcsón! Figyelem, csak hardcore szódázóknak!
- gban: Meghalt Chuck Norris
- Elektromos rásegítésű kerékpárok
- suste: Openwrt Barrier Breaker 14.07 saját verzió Tp-link routerekre
- sziku69: Fűzzük össze a szavakat :)
- talmida: Változások 2. rész
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- TheLázs: Nem tudom átugrani az árnyékomat,
Új hozzászólás Aktív témák
-
nyunyu
félisten
válasz
bambano
#4737
üzenetére
Van amikor a számítási/lekérdezési sebesség fontosabb, mint a redundancia.
Ha csinálsz egy aktuális raktár nézetet, amiben összejoinolod az eredeti raktár táblát a mozgatások szummájával, és ebből dolgozik a következő lépést meghatározó lépés, akkor minden egyes lépés kiértékelésénél a DBnek egyesével újra kell számolnia az eddigi lépések eredményét, ahelyett, hogy a letárolt köztes értéket használná.
Ez ugyan elegáns, de nem hatékony.(Épp most kínlódunk azzal, hogy mindenféle BI riportokat kell készíteni, de többszázezer soros táblákat kell joinolni, szummázni, és az eredmény kb. 40k sor/nap.
BI meg állandóan beledöglik, amikor így-úgy szűrve belekérdez a DBben tárolt nézetbe.
Úgyhogy írhatok egy jobot, ami naponta lefuttatja a kb. egy percig futó queryt, és insert into-zza egy táblába, aztán onnan fog select *-ozni a BI, nem az eddigi nézetből.)
Új hozzászólás Aktív témák
- Telefon felvásárlás!! Samsung Galaxy S25, Samsung Galaxy S25 Plus, Samsung Galaxy S25 Ultra
- ÁRGARANCIA!Épített KomPhone i5 14600KF 16/32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- iPhone 17 Pro 256 GB - Bontatlan !! www.stylebolt.hu - Apple eszközök - Számlás
- Dobozos! Xbox Series X 1 TB + kontroller 6 hó garancia, számlával!
- Dell 27" USB-C Hub Monitor - P2723DE - 27% ÁFÁs
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
