Hirdetés
- MWC 2026: csápolt a robot, majd dobott egy hátraszaltót
- Apple Watch Sport - ez is csak egy okosóra
- Netfone
- Google Pixel 10a – évismétlés
- Google Pixel 10 Pro XL – tíz kicsi Pixel
- Xiaomi 17 Ultra - jó az optikája
- Brutális akkumulátort kaphat a Honor X80 GT
- Itt a Galaxy S26 széria: az Ultra fejlődött, a másik kettő alig
- One mobilszolgáltatások
- iPhone topik
Ú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?:))
- CASIO órák kedvelők topicja!
- Még tavasszal befut az Xbox mód a Windows 11-hez
- Arc Raiders
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- Star Trek
- MWC 2026: csápolt a robot, majd dobott egy hátraszaltót
- Amazon
- Apple Watch Sport - ez is csak egy okosóra
- Apple MacBook
- Gaming notebook topik
- További aktív témák...
- ASUS TUF Gaming VG32UQA1A VA / 4K / 160hz
- Lenovo Legion Slim 5 Ryzen 7 7840HS 16GB 1000GB RTX 4060 OLED 120Hz 1év garancia
- Precision 5570 27% 15.6" 4K+ IPS érintő i7-12700H RTX A2000 32GB 1TB NVMe ujjlolv IR kam gar
- Lenovo Legion Slim 5 Ryzen 7 7840HS 16GB 512GB RTX 4060 OLED 120Hz 1év garancia
- Gainward RTX 5060 Ti Python III 16GB GDDR7 128bit (NE7506T019T1-GB2061T) Videokártya
- Surface Pro 7+ i5-1135G7 16GB 512GB 1 év garancia
- Iphone 15 Mobiltelefon 128Gb 100% akkumulátorral
- ÁRGARANCIA!Épített KomPhone i5 12400F 16/32/64GB RAM RTX 5060 Ti 8GB GAMER PC termékbeszámítással
- Tablet felvásárlás!! Apple iPad, iPad Mini, iPad Air, iPad Pro
- HP EliteBook 830 G8 13,3" i7 -1185 G7, 8-16GB RAM, SSD, jó akku, számla, 6 hó gar
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest

