Ú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?:))
- OLED TV topic
- Székesfehérvár és környéke adok-veszek-beszélgetek
- aquark: KGST processzorok 1984-ig
- LED világítás a lakásban
- ZIDOO médialejátszók
- mefistofeles: Az elhízás nem akaratgyengeség!
- E-book olvasók
- Mibe tegyem a megtakarításaimat?
- Anime filmek és sorozatok
- Autós kamerák
- További aktív témák...
- BONTATLAN Zacskós ThinkCentre M70s SFF Business Időtálló Asztali gép -50% i5-14500 16/512 770 Magyar
- Thrustmaster T300 RS Alcantara + Wheel Stand Pro Állvány
- 4K Gamer PC i7-14700K / RTX 5070 12GB / 32GB DDR5 / 1TB NVMe / NZXT Ház - 280 AIO - Beszámítás
- BESZÁMÍTÁS! MSI Z690 i5 12400F 32GB DDR4 512GB SSD RX 6750XT 12GB ASUS A31 PLUS TG ARGB Seasonic750W
- BESZÁMÍTÁS! MSI A320M R5 1600 8GB DDR4 240GB SSD GTX 1050Ti 4GB ZALMAN T3 PLUS DeepCool 400W
- Gamer PC-Számítógép! Csere-Beszámítás! R7 7800X3D / 32GB DDR5 / RX 9070 / 2TB SSD!
- Beszámítás! Lenovo Legion 5 15ACG6 165Hz Gamer notebook -R7 5800H 32GB DDR4 1TB SSD RTX 3070 8GB W11
- HIBÁTLAN iPhone 14 Plus 128GB Yellow -1 ÉV GARANCIA - Kártyafüggetlen, MS4472
- Lenovo ThinkPad dokkolók: USB-C 40A9/ 40AY/ 40AS/ Thunderbolt 3 40AC/ Hybrid USB-C DisplayLink 40AF
- Blackview Link 8 12,7" Tablet
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest


