- Szünetmentes tápegységek (UPS)
- Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
- Milyen egeret válasszak?
- Amlogic S905, S912 processzoros készülékek
- Házimozi belépő szinten
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Alapértelmezett konfiguráción sok Core CPU-nak lehet stabilitási gondja
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Milyen házat vegyek?
- Androidos tablet topic
Hirdetés
-
Toyota Corolla Touring Sport 2.0 teszt és az autóipar
lo Némi autóipari kitekintés után egy középkategóriás autót mutatok be, ami az észszerűség műhelyében készül.
-
Képeken az egyik kameráját elvesztő Sony Xperia 10 VI
ma Részletes anyag került fel az internetre a Sony idei középkategóriás telefonjáról, három helyett két hátlapi kamera várható.
-
Ilyen lesz a SteamWorld Heist II
gp A folytatás a tervek szerint a nyár folyamán, pontosabban augusztus elején érkezik.
Új hozzászólás Aktív témák
-
Speeedfire
nagyúr
Ha jól tudom nem minden esetben gyorsabb a nosql. pl ahogy hallom az fb szerű falaknál van igazán nagy haszna.
Gondolom ez lenne az sql-es netbeans. Nem ismerem, meg vagyok elégedve a mysql workbench-el.
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
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
- Robot fűnyírók
- Mr Dini: Mindent a StreamSharkról!
- Óra topik
- Autós topik
- Szünetmentes tápegységek (UPS)
- iPhone topik
- Kínai, és egyéb olcsó órák topikja
- Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
- Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
- A fociról könnyedén, egy baráti társaságban
- 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