- Kormányok / autós szimulátorok topikja
- Bambu Lab 3D nyomtatók
- Kompakt vízhűtés
- NVIDIA® driverek topikja
- HiFi műszaki szemmel - sztereó hangrendszerek
- Bluetooth hangszórók
- Vezetékes FEJhallgatók
- AMD GPU-k jövője - amit tudni vélünk
- Sony MILC fényképezőgépcsalád
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
Ú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?:))
- Xbox Series X|S
- Otthoni hálózat és internet megosztás
- Budapest és környéke adok-veszek-beszélgetek
- Folyószámla, bankszámla, bankváltás, külföldi kártyahasználat
- Kormányok / autós szimulátorok topikja
- Gránit mosogató
- Milyen légkondit a lakásba?
- Gumi és felni topik
- ASZTALI GÉP / ALKATRÉSZ beárazás
- iRacing.com - a legélethűbb -online- autós szimulátor bajnokság
- További aktív témák...
- Szép Dell Precision 5560 Slim Tervező Vágó Laptop -70% 15,6" i7-11850H 64/1TB RTX A2000 4GB UHD 4K
- Acer Nitro V 16 AI Gamer Laptop! Ryzen 7 260/RTX 5070/32gb DDR5/2TB SSD/2560x1600/180hz/Beszámítok!
- Szép Dell Precision 5560 Slim Tervező Vágó Laptop -70% 15,6" Xeon W-11955M 64/1TB RTX A2000 4GB FHD+
- AOC CQ27G2S Monitor (2K/VA/165hz)
- Samsung C27F396FHR Monitor
- DDR3 BAZÁR! 8GB 16GB 1333MHz 1600MHz 2400MHz DDR3 memória garanciával hibátlan működéssel
- Bomba ár! Dell Latitude E7240 - i7-4GEN I 16GB I 256SSD I 12,5" HD I HDMI I Cam I W10 I Garancia!
- ÁRGARANCIA!Épített KomPhone i7 14700KF 32/64GB RAM RTX 5070Ti 16GB GAMER PC termékbeszámítással
- Dixit 4 Eredet (bontatlan, fóliás kártyacsomag)
- Bomba ár! HP Elitebook Folio 9470M - i5-3GEN I 8GB I 256GB SSD I 14" I DP I Cam I W10 I Garancia!
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest