- Dell notebook topic
- HiFi műszaki szemmel - sztereó hangrendszerek
- Alapértelmezett konfiguráción sok Core CPU-nak lehet stabilitási gondja
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- Steam Deck
- Azonnali informatikai kérdések órája
- Milyen monitort vegyek?
- Autóhifi
- AMD GPU-k jövője - amit tudni vélünk
- Google Chromecast topic
Hirdetés
-
Spyra: akkus, nagynyomású, automata vízipuska
lo Type-C port, egy töltéssel 2200 lövés, több, mint 2 kg-os súly, automata víz felszívás... Start the epic! :)
-
Letartóztatták a bitcoin-Jézust
it Amerikai adókerülés vádjával, Spanyolországban tartóztatták le a bitcoin-Jézusként ismert Roger Vert.
-
iPaden is vége az App Store monopóliumának
ma Ősztől lehet alternatív alkalmazásboltból telepíteni az EU tagállamaiban.
Új hozzászólás Aktív témák
-
modder
aktív tag
Nem tudom neked mit tanítottak RDBMS-ekkel kapcsolatban egyetemen, de ha érdekel a téma, akkor tényleg érdemesebb lenne előbb jobban utána járni.
Ez a "jobban kedvelik szétbontani több szelektre egy join-t" hát ez rohadt sokmindentől függ. pl attól, hogy abban a rendszerben, amit átvettél fingjuk nem volt mi fán terem az sql, ezért a legegyszerűbb módszerhez folyamodtak, amit még ismertek. Egy megfelelően indexelt, nagy adathalmaznál (értsd: több millió sor) particionált táblákból álló relációs adatbázisban 3 tábla joinja gyorsabb lesz, mint 3 szelekttel lekérdezni. Nem illik okosabbnak lenni az adatbázisnál.
"NoSQL majdnem minden esetben gyorsabb az relációs adatbázisnál" -- ez is hatalmas tévhit. Még elosztott rendszerben is. nézd meg pl az alábbi cikket
Twitter, PayPal reveal database performanceNoSQL-re szeritem áttérni két szélsőséges esetben érdemes:
-- elosztott az alkalmazásod, több szerveren fut, és sokkal több írás történik az adatbázisba, mint lekérdezés (facebook eset)
-- több szerveren fut az alkalmazásod, és ki akarod használni az elosztott "NoSQL" (bár nem ugyanazt jelenti) által alapból nyújtott terheléselosztást anélkül, hogy bajlódni szeretnél egy MySQL clusterezéssel.Az, hogy mitől lehet lassú egy relációs adatbázis sokmindentől függ: rosszul megtervezett indexek, rosszul megtervezett lekérdezések, rossz particionálás, table lock használata írásnál sok írás mellett (érdemes inkább optimistic locking-ot használni)
Az autoincrement pedig azért is ugorhat, mert tranzakció végén rollback volt, új adat nem került beszúrásra véglegesen, de az auto increment érték nőtt.
Új hozzászólás Aktív témák
- LEGO klub
- Dell notebook topic
- Crypto Trade
- Építő/felújító topik
- eBay-es kütyük kis pénzért
- Vicces képek
- Samsung Galaxy S23 Ultra - non plus ultra
- Debrecen és környéke adok-veszek-beszélgetek
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- Vodafone otthoni szolgáltatások (TV, internet, telefon)
- További aktív témák...
- EDIFIER R1700BTS hangfal pár makulátlan, új állapotban, 2 év hivatalos garanciával, alkalmi áron
- LG OLED55B23LA 2 Év GYÁRI GARANCIA
- Apple iPhone XR 128GB, Kártyafüggetlen, 1 Év Garanciával
- Gamer PC , i7 12700KF , RTX 3080 Ti , 64GB DDR5 , 960GB NVME , 1TB HDD
- Intel PC , i5 8500 , 1660 6GB , 32GB DDR4 , 512GB NVME , 500GB HDD
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest