- iPhone topik
- Vodafone mobilszolgáltatások
- Telekom mobilszolgáltatások
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Eleglide C1 - a középérték
- Milyen okostelefont vegyek?
- Android szakmai topik
- DIGI Mobil
- Android alkalmazások - szoftver kibeszélő topik
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
Hirdetés
-
Kapnak egy rakás reklámot a Roblox játékosai
it Videohirdetésekre készülhetnek ezentúl a virtuális világokban a Roblox játékosai.
-
A Colorful "fagyosan kompakt" alkatrészekkel megy elébe a nyárnak
ph A vállalat többek között egy slim profilos léghűtővel, egy helytakarékos táppal és egy ITX-es házzal adott magáról életjelet.
-
Snapdragon 8-as szériával várhatók a Honor 200-ak?
ma A Honor 200 állítólag a 8s Gen 3-at, a 200 Pro változat pedig a 8 Gen 3-at használja majd.
Ú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
- Gördeszka topic
- Az NVIDIA szerint a partnereik prémium AI PC-ket kínálnak
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Xbox Series X|S
- Anglia - élmények, tapasztalatok
- Konzolokról KULTURÁLT módon
- BestBuy ruhás topik
- Milyen billentyűzetet vegyek?
- 3D nyomtatás
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- További aktív témák...