Hirdetés
- Vivo X200 Pro - a kétszázát!
- Android alkalmazások - szoftver kibeszélő topik
- Google Pixel topik
- Samsung Galaxy S24 - nos, Exynos
- Milyen okostelefont vegyek?
- Oldalról rápillanthatunk a Vivo X300-ak kameráira
- Érintésnélküli fizetési megoldások - PayPass via NFC
- Leminősítik az S26 Ultra zoomkameráját
- Apple iPhone 16 Pro - rutinvizsga
- Poco F7
Új hozzászólás Aktív témák
-
Drizzt
nagyúr
válasz
Orionk #10365 üzenetére
Egyfelől van SQL topic, ez oda jobban illene.
Másfelől:
- Indexeket kell használni. Azt az oszlopot kell indexelni, ami a where feltételben szerepel elsősorban. Ebből is elsősorban azok lesznek gyorsak, amikor konkrét értékre vonatkozik a feltétel, vagy arra, hogy egy érték egy tartományban van-e. Ha több oszlop is van a keresésben, lehet kompozit indexeket definiálni. Ha pl.: van a,b,c oszlopra egy indexed, azt az olyan feltételekre lehet használni, ahol vagy csak a-ra, vagy a-ra és b-re, vagy a-ra, b-re, s c-re van megszorító feltétel megadva. Az index gyorsítja a keresést, de lassítja a beszúrást, törlést. Ezen kívül még fontos, hogy ha csak az indexben szereplő dolgokat fogsz kikeresni a select-tel, akkor az szinte biztosan csak memóriában fog történni, de a többi mező lekérdezéséhez már lehet a diszkhez kell fordulni, ami lassítani fog erősen. Másik megfontolás a select oszlopok számánál, hogy minden extra oszlop megnöveli a visszaadott adathalmaz méretét, emiatt ha a sávszélesség probléma az adatbázis és az alkalmazás szerver között, akkor ronthat a sebességen. Erre szoktak DTO-kat használni(olyan objektum, ami csak a teljese tábla oszlopainak egy részét tartalmazza. Azt, amire éppen minimálisan szükség van az adott probléma megoldásához.).
- Nem árt megnézni azt sem, hogy a lekérdezés tényleg fogja-e használni az elkészített indexet. Erre általában adatbázisonként különbözik, hogy milyen paranccsal, de le lehet kérdezni, hogy mi lesz a query excution plan. Abból kiderül, hogy fog-e használni indexet, vagy nem. Illetve melyiket. A kritikus lekérdezésekre szerintem mindig ellenőrizni kell.
- Ha gyakran használ az ember joint, akkor érdemes lehet elgondolkodni a joinolt tábla foreign key-ként használt oszlopának indexelésén. Ez nagyban felgyorsíthatja a join-ok sebességét.
- Ha a beszúrás és a törlés is nagyon gyakran történik meg és a tábla nagy, akkor érdemes lehet particionálni a táblát több részre. Mondjuk ha neveket tárolsz, akkor az egyik tabla csak a-b, a másik c-d, ... kezdetű neveket tartalmazza. Viszont ilyenkor pl. nehéz lesz jó foreign keyeket definálni a nevekre, s sok egyéb komplikáció előjöhet. Ha ilyen jellegű a probléma, akkor lehet érdemesebb valamilyen noSQL db-t választani RDBMS helyett.
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- exHWSW - Értünk mindenhez IS
- Vivo X200 Pro - a kétszázát!
- Nem tetszik pár profi eSport játékosnak, hogy Intel CPU-val kell játszaniuk
- Autós topik
- BestBuy topik
- Luck Dragon: Asszociációs játék. :)
- Android alkalmazások - szoftver kibeszélő topik
- AliExpress tapasztalatok
- Google Pixel topik
- Samsung Galaxy S24 - nos, Exynos
- További aktív témák...
- Enermax Liqmax III ARGB 360 (3/2 ventis) INGYEN FOXPOST
- MacBook Air M3 13.6" 8/256 100% akkumulátor
- Eladó egy oneplus 9 pro 256/12
- !!AKCIÓ!! AppleCare+ biztosítás és kiterjesztett garancia - Apple hivatalos biztosítás - Számlával
- Enermax ETS-T50 W-ARGB (Brutál hiányos+hibás alkatrésznek csakis) INGYEN FOXPOST
- Honor 200 Lite 256GB, Kártyafüggetlen, 1 Év Garanciával
- ÁRGARANCIA!Épített KomPhone i9 14900KF 32/64GB DDR5 RAM RTX 5070 12GB GAMER PC termékbeszámítással
- Asus ROG Zephyrus G14 - 14"2.8K OLED 120Hz - Ryzen 9 8945HS - 16GB - 1TB - RTX 4060 -2,5 év garancia
- Microsoft Surface Laptop 5 13,5" i7-1265U 16GB 512GB magyarbill 1 év garancia
- GYÖNYÖRŰ iPhone 13 256GB Pink -1 ÉV GARANCIA - Kártyafüggetlen, MS3425, 94% Akkumulátor
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest