Hirdetés
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- sziku69: Fűzzük össze a szavakat :)
- sziku69: Szólánc.
- Luck Dragon: Asszociációs játék. :)
- Hieronymus: Hogyan parkolj hátramenetben profi módon
- vrob: Próbálkozás 386 alaplap újraélesztésre
- bambano: Bambanő háza tája
- gban: Ingyen kellene, de tegnapra
- Luck Dragon: MárkaLánc
- Luck Dragon: Óraátállítás
Ú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?:))
- Milyen egeret válasszak?
- Crimson Desert
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- NVIDIA GeForce RTX 3080 / 3090 / Ti (GA102)
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Apple MacBook
- Milyen billentyűzetet vegyek?
- Samsung Galaxy A56 - megbízható középszerűség
- GL.iNet Flint 2 (GL-MT6000) router
- HiFi műszaki szemmel - sztereó hangrendszerek
- További aktív témák...
- i5 14400F/MSI RTX 5070 GAMING TRIO OC/Corsair 32GB DDR5 6000Mhz/Samsung 980 Pro 1TB/Be quiet650WGold
- Tamron 24-70mm f2.8 Di VC USD G2 (Nikon F) eladó!
- Steelseries Arctis 9X Wireless for xbox + Xbox dongle for PC
- ASUS ROG STRIX GeForce RTX 4090 WHITE OC EDITION 24GB - Alza garancia 2027.03.19 - BESZÁMÍTOK!
- ASUS ExpertBook P5 Ultra 7 / 32GB / 1TB / 2560x1600 MATT 144Hz / Gari 2028 06 05-ig!
- Prémium! Bambulab bontatlan filamentek (PLA - PETG- ABS) ÁFÁS- számlával eladóak készletről!
- Ventilátorok 120/140mm és modding termékek kitűnő árakon! Mennyiségi kedvezmény!
- HP Elitebook 850 G8 15,6" i5 1135 G7, 8-16GB RAM, SSD, jó akku, számla, 6 hó gar
- 270 - Lenovo Yoga Pro 9 (16IAH10) - Intel Core U9 285H, RTX 5070 (ELKELT)
- Apple iPhone 17 Pro Max 256GB Cosmic Orange Újszerű állapot 100% akku (2 ciklus)
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
