- Luck Dragon: Asszociációs játék. :)
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- sziku69: Szólánc.
- lacixtal: Laci XTAL - Emlékproffil
- sziku69: Fűzzük össze a szavakat :)
- eBay-es kütyük kis pénzért
- btz: Internet fejlesztés országosan!
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Lenry: Windows 11 telepítése inkompatibilis gépre
- Argos: Adjátok vissza a netet! - szeretnék elaludni!
Ú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
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- R7 9800X3D/XFX 7900GRE/2x16GB DDR5 6000Mhz/2TB NVMe SSD
- Szép állapot!! Hátlapon kisebb kopások!!! Samsung Galaxy S20 FE SM-G780G/DS - világoskék
- MacBook Air M1 / 2020 / Ezüst / 13" / 256 GB / 8 GB / DOBOZ / GYÁRI TARTOZÉKOK /
- Nagyon szép állapot!!! Samsung Galaxy A13 SM-A137F/DSN - fehér
- i5 HP Pavilion DV7 laptop
- BESZÁMÍTÁS! MSI B450M R5 5500 16GB DDR4 512GB SSD RTX 2060 Super 8GB Rampage SHIVA ADATA XPG 600W
- Ryzen 7 5800XT: Gyorsabb, Erősebb, Tiéd lehet még ma! Rèszletre is!
- AKCIÓ! Apple Macbook Pro 16" 2019 i9 9980HK 64GB DDR4 512GB SSD Radeon Pro 5500M garanciával
- Honor 90 256GB, Kártyafüggetlen, 1 Év Garanciával
- Lenovo ThinkCentre M720q/ Dell OptiPlex 3070/ Hp EliteDesk 800 G4-G5 mini, micro PC-Számla/garancia
Állásajánlatok
Cég: FOTC
Város: Budapest