Új hozzászólás Aktív témák
-
Taci
addikt
válasz
sztanozs
#5137
üzenetére
Köszönöm szépen a részletes magyarázatot és okfejtést! (És mindenki másnak is, aki segített!)
Mindezt figyelembe véve még az az elméleti kérdés jutott eszembe, hogy:
Csakis és kizárólag a legfrissebb dátumú elemek vannak elől. Egyszerre mindig csak 4 elemet kap a felhasználó, mindig a (kiválasztott kategóriának stb. megfelelő) 4 legfrissebb dátumút. Mindig.
Ezek a rekordok pedig 5 percenként kerülnek az adatbázisba, kb. 5-10-esével / forrás, 20-30 helyről egyszerre.
Aztán ha görget a lap aljáig (mínusz X pixel), akkor következő 4 és így tovább. 25 görgetés 100 rekord. 250 görgetés 1000 rekord. 750 görgetés 3000 rekord. Ennyit nem fog senki soha egy huzamban végig pörgetni a szűrési feltételek módosítása, vagy ráfrissítés nélkül (ahol 0-ról kezdődik az egész).
Plusz a következő "4-esbe" az időközben bekerült új rekordok is benne kerülnek, szóval egyre kevésbé valószínű, hogy "túl mélyre ér" (a rekordok időbélyegzőit figyelembe véve).Így a tábláknak (items) nem kellene csak max 3 ezer (az items_categories-nak pedig átlag 3 kategória/item-mel számolva max 9 ezer) rekordot tartalmaznia. Tehát a mostani példa adatbázisomnak (300e / 900e) a század részét.
Most levittem erre a számra a rekordok számát, és így az eddigi 0,5 mp-es lekérdezés 0,01 mp-re (sőt inkább alá) szelídült. Azért ez már élhető. Még ha a duplájával számolnék (rekordszám) a biztonság kedvéért, akkor is.
A legfrissebb 3000 utáni rekordra pedig csak és kizárólag a szöveges keresésnél lehet szükség, ott pedig belefér egy lassabb (Union miatt) lekérdezés is.
Illetve még akkor is, ha mondjuk csak 1 kategóriát néz, és abban a legfrissebb 3ezerből csak kb. 100 rekord van (30+ kategória van), és 25-től többet scrollozik - ami azért nem olyan sok. Inkább megnéztem most gyorsan 6e/18e rekordra, 0,03 mp alatti a lekérdezés, és így "biztonságban is lennék" minden téren.A kérdésem az lenne, hogy:
1) ezt jó ötletnek tartjátok-e,
2) ha igen, akkor hogyan lenne jobb az "archív" rekordokat tárolni? Minden, ami nem a 3000 (vagy 6000) legfrissebben van benne, az legyen egyetlen egy darab (mondjuk items_archive) táblába áthelyezve? Mert ha jól emlékszem, azt mondtátok, hogy ahol ugyanazok a mezők vannak, nem jó ötlet szétszedni.
Viszont azt is mondták, hogy mindenképp kell "archiválni" is.
Tehát egy nagy archiv tábla legyen (items_archive), vagy legyen mondjuk évenkénti? (items_archive_2021, items_archive_2022 stb.)
Úgy gondolom, csak kereséseknél kellene használni az archívokat, normál használattal görgetve oda már "nem jut le senki" (de biztos ami biztos, felkészíteném arra is).@nyunyu: Az SQL Server Express-t most raktam fel, már a táblákat töltöm. Kíváncsi leszek az ottani eredményekre.
Új hozzászólás Aktív témák
- Fejhallgatós találkozó
- exHWSW - Értünk mindenhez IS
- Xiaomi 17 - még mindig tart
- Jövedelem
- Forradalomi előrelépésként jellemzi az NVIDIA a DLSS 5-öt
- Kerékpárosok, bringások ide!
- Villanyszerelés
- PlayStation 5
- Counter-Strike: Global Offensive (CS:GO) / Counter-Strike 2 (CS2)
- Itt a Galaxy S26 széria: az Ultra fejlődött, a másik kettő alig
- További aktív témák...
- Felsőkategóriás Gamer PC-Számítógép! Csere-Beszámítás! 7800X3D / RTX 5070 / 32GB DDR5 / 2TB SSD!
- ÁRGARANCIA! Épített KomPhone i5 12400F 16/32/64GB RAM RTX 5060 8GB GAMER PC termékbeszámítással
- MSI Prestige A16 AI+ Ryzen AI 9, 32GB DDR5 7500, QHD+ 165Hz csúcskategóriás ultralaptop!
- HP ProBook 445 G8 14" Ryzen 3 5400U, 8GB RAM, 256GB SSD, jó akku, számla, 6 hó gar
- Dell Precision 5530 15,6" FHD, i7 8850H, 16GB RAM, Quadro 4GB VGA, 512GB SSD, jó akku, számla, gar
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
