AJAX táblázat-rendezés
2007-10-13T11:41:50+02:00
2007-10-14T19:44:11+02:00
2022-07-19T05:12:30+02:00
  • Köszönöm mindenkinek a válaszokat. Tettem ma még egy másik vonalon próbát, és tényleg időt betöltődési takaríthatok meg evvel a módszerrel, csak szimplán hülyeség volt tőlem, hogy a 2k rekordot akartam az AJAX-al behúzni egyben.

    Köszi mégegyszer! Megyek is belevágok :)
    Mutasd a teljes hozzászólást!
  • A 2000 elem rendezett lekérése, az 2000 elem rendezett lekérését jelenti. Ha erre raksz egy limitet, akkor az ezen a rendezett halmazon lesz értelmezve, magyarul ha 20 szeletben kéred le, és azt összerekod (a kliensen), akkor ugyanazt a rendezett 2000 elemű halmazt kapod eredményként. A kérés optimalizálása az SQL szerver dolga. Nyilván összességében nem lesz olyan gyors, mintha egyből kérnéd el a 2000 rendezett sort, de nem is lesz 20x lassabb a folyamat.

    Az aszinkron kéréseknél, amikor darabokból állítod elő a teljes lapot, arra kell figyelni, hogy minden szelethez érkező kérést ugyanazon az eredményhalmazon értelmezd. Magyarán be kell vezetni egy verziót az egészhez, és minden módosításnak frissíteni kell a verziót (Log, TimeStamp). A kliens tudja, hogy mi volt az aktuális verzió, amikorra vonatkozóan elindította az aszinkron kéréssorozatot, ezt a szeveren ellenőrizve tudod validálni a folyamatot. Ha nem stimmel a verzió, akkor faultot ad vissza, amiből a kliens tudja, hogy az adathalmaz változott. Ilyenkor újra kell indítani az egész folyamatot az aktuális verzióval. (Én ennek kezelésére vezettem be egy WCF service-t az aspx és az AJAX közé)

    Ha az adathalmaz sűrűn változik, akkor ez a darabonkénti lekérés nem nyerő ötlet. Ilyen adathalmaznál marad az egyszerre lekérdezés, vagy a dinamikus lapozás (amikor az eredményhalmaz részével együtt megkapja az UI a teljes rekodszámot, és eszerint minden szelet megérkezésekor frissíti a lapozásért felelős felületet is - mint az ASP.NET).
    Mutasd a teljes hozzászólást!
  • A limit, az order by és a where részek ok. Ennél tovább nem jutottam - ez tény - a rendezésben.

    Csak annyi a gondom, ha 200 elemes határ miatt megint lekérdezni kell sql-ben az mennyivel javítja a mostani helyzetet, hogy 100 elem van és oldallépésnél, vagy lekérdezésnél újra kell tölteni az oldalt és új sql jön?
    Ez az amit igazán nem értek. Mert amit itt nyerek a sebességben, az sztem (első ránézésre) nem éri meg a váltást. De lehet 1részt rosszul látom, másrészt lehet, hogy az sql kezelésével nem vagyok eléggé tisztában!
    Mutasd a teljes hozzászólást!
  • csak a 200 betöltöttet rendezem AJAX-al, ekkor megspórolom az újratöltést, DE logikátlan az egész működés, hiszen 2000 rekordból 200-at rendezve látok, és maradék 1800-at nem látok.
    Példa: van 1 általam gyártott webshop, ha oda ezt így betenném, akkor szűrés nélkül az admin megnézi a termékeket. 200 lejön neki, shiny, trendi, ajax szép frankó. Rendez az árra, mivel a legolcsóbb 20 termék árát növelni akarja.
    Igen ám, de csak a 200 termék legolcsóbb 20 termékét fogja látni, ami az 2000 termék 20 termékéhez képest ugye nem jó.


    Fogalmad sincs az SQL szerveroldali rendezésről és lapozásról, ugye? Akkor nem szóltam.
    Mutasd a teljes hozzászólást!
  • Lehet, hogy hülyeséget mondok, ilyen sok adattal még nem dolgoztam, de esetleg a kliens oldali xslt?

    Először csinálsz egy xsl stíluslapot, ami a táblázat megjelenítését végzi, aztán PHP-val csinálsz egy xml fájlt a lekérdezett adatokból és a kliens oldalon összefésülöd a kettőt. Így elmarad a DOM építgetés.
    Mutasd a teljes hozzászólást!
  • Ez mért baj? Tudod az aktuális adag kezdő indexét és az elvárt elemek számát, ezt az SQL is megérti (MySQL-nél asszem LIMIT, MS SQL-nél ROW_NUMBER). Ha lapozható felületetet csinálsz, akkor is ilyen lekérdezés fogja baolvasni az adatokat.


    Megpróbálom egy példával szemléltetni, miért baj:
    nev, e-mail, msn azonosito
    xxx, a@b.hu, mittomen@yahoo.com
    xxx, a@b.hu, mittomen@yahoo.com
    xxx, a@b.hu, mittomen@yahoo.com
    xxx, a@b.hu, mittomen@yahoo.com
    xxx, a@b.hu, mittomen@yahoo.com

    pl ebből van 2000 db pl, nyilván más adatokkal

    A framework, amit próbáltam szintén oldalakra bontotta, tehát volt 20 oldalam, minden oldalon 100 sor. A gond azzal volt, hogy ha nincs szűrés kritérium beállítva, akkor előbb betölti a 2000 sort, majd kiteszi az első oldalra a 100-at. Ez volt 40-60 sec. Horror sok.
    Ekkor ugye a táblázat név oszlopára kattintva (rendezés) újrarendezte mind a 2000 rekordot és megjelenítette a rendezés alapján azt a 100-at amelyik oldalon álltam.
    Ez volt 10-20 sec. Horror sok szintén.

    Miért nem jó a darabolós megoldás? Ha csak 200-at töltök be az SQL-be?
    Azért mert ebben az esetben 2 lehetőség van:

    a) csak a 200 betöltöttet rendezem AJAX-al, ekkor megspórolom az újratöltést, DE logikátlan az egész működés, hiszen 2000 rekordból 200-at rendezve látok, és maradék 1800-at nem látok.
    Példa: van 1 általam gyártott webshop, ha oda ezt így betenném, akkor szűrés nélkül az admin megnézi a termékeket. 200 lejön neki, shiny, trendi, ajax szép frankó. Rendez az árra, mivel a legolcsóbb 20 termék árát növelni akarja.
    Igen ám, de csak a 200 termék legolcsóbb 20 termékét fogja látni, ami az 2000 termék 20 termékéhez képest ugye nem jó.

    Jön emiatt a b) megoldás:

    b) rendezésre új sql-t húzok be, és 2000 rekord, sql-ben szűrés és kipakolás. Ez esetben semmi értelme az AJAX-nak, most is ezt csinálom AJAX nélkül, max van benne egy +2 sec-es oldal újratöltés.

    Ez a gondom.
    Emiatt kérdeztem, hogy van-e értelme átállni nagyobb mennyiségű adatnál?
    Alapból már szűrőkkel töltöm be a progim, amihez ezt gondoltam alkalmazni, de van amikor minden elemet nézek, és olyankor gyak. használhatatlanná lassulna a program az adatmennyiség miatt.
    Mutasd a teljes hozzászólást!
  • AJAX-szel nem szerencsés ekkora adathalmaz kezelni, mert a JavaScript motor fogja előállítani a renderelendő HTML-t (még akkor is, ha csak sima innerHTML-be megy az előrerenderelt darab), ami jóval lassabb lesz, mintha egyből az oldalértelmező kapná a nyers html adatokat. Ekkora várható mennyiségnél én már be szoktam vezetni a lapozást egy AJAX felületen.

    - gondoltam, hogy darabolni kellene, pl 200-anként újratöltődés, közben AJAX -> ez sem korrekt megoldás, hiszen minden AJAX rendezésnél (ha nincsen szűrő) a teljes tábla adatai kellenek, ergó sql lekérés megint és betölteni minden adatot...


    Ez mért baj? Tudod az aktuális adag kezdő indexét és az elvárt elemek számát, ezt az SQL is megérti (MySQL-nél asszem LIMIT, MS SQL-nél ROW_NUMBER). Ha lapozható felületetet csinálsz, akkor is ilyen lekérdezés fogja baolvasni az adatokat.

    Ha már mindenképp kell az összes rekord AJAX felületen, akkor használd ki, hogy aszinkron. Oszd fel a táblát, mondjuk 20 részre, mindegyik rész egy AJAX placeholder, és mindhez külön kérést indítasz egyszerre, melynek paramétere a placeholder index (plusz a szűrési paraméterek, ha vannak). A szerveren ki tudod ebből számolni, hogy mik lesznek a lapozási paraméterek, ami megy az SQL LIMIT-be. Lekéred a session-be a rekordok számát ha még nem van ott (vagy nemtom ezt PHP-ben hova érdemes tenni, én ASP.NET-nél egyszerűen a ViewState-t használtam), és tudod, hogy hány placeholder van, így ezekből ki lehet számolni, hogy mik legyenek az egyes területek lapozóindexei. Ha kevesebb, mint ahány terület van, akkor a végén üres html-darabot küldez, de ez egyértelmű.

    Így a böngészőben darabonként fog felépülni a táblázat, ahogy sorban (pontosabban össze-vissza) megérkeznek a részek a szerverről (érdemes a placeholderbe alapból egy "Betöltés..." feliratot renderelni).

    Kódot nem tudok mutatni, mert én ASP.NET AJAX + MS SQL-ben csináltam ilyet.

    SZERK: ASP.NET-tel ez a megoldás nem tud működni UpdatePanel módszerrel, mert minden darab egy teljes page roundtripnek számít. Írtam wgy WebHtpp WCF service-t, ami stream-ben nyomja ki a HTML framgmentet, amit egy külön, csupaszított ASPX oldal renderelt. A drabokat kézi JS rakta össze.
    Mutasd a teljes hozzászólást!
  • nagyon köszi a választ, megcsinálom a tesztet...
    utána még írok majd, hátha vkit későbbiekben érdekel az eredmény!
    Mutasd a teljes hozzászólást!
  • elképzelni el tudom, megvalósitani is meg lehet. az hogy milyen sebességű lesz... hát nemtudom. mivel a user gépén fut, ismerni kellene a felhasználók táborát. ha sok esetben gyenge gépekkel dolgoznak, akkor nem ajánlom, amiga js dolgozgat, addig azt érezheti hogy lefagyott a böngészője. de a legnagyobb hangsúly azon van, hogy mennyi időbe kerül js-nek hogy rendezzem majd felépitsen egy táblát a megfelelő (pl appendchild, stb) függvényeket használva.
    csinálj fals adatokakl egy sebességmérést, hogy mennyibe fáj a böngészőnek egy 2000x valahány-as táblát legenerálni valahány js tömbből, amibe az adatok véletlenszerűen kerültek bele. nem is kell értelmes adat, kb ilyen is megteszi:
    <?php print "<script>\n"; for ($i=0;$i<2000;$i++)print " tomb[".$i."]=".rand(0,1000); print "</script>\n"; ?>
    Mutasd a teljes hozzászólást!
  • nem vagyok nagy js vagy ajax guru, mindenesetre kiindulásnak köszi az irányt, legalább látom merrefelé kell tovább olvasgatnom.

    a postod egyébként azt is jelenti, hogy el tudod képzelni (vagy tisztában vagy avval), hogy megvalósítható tisztességesen nagyobb méretű táblánál ilyen "vezérlés"?
    Mutasd a teljes hozzászólást!
  • hmm, mi lenne ha az adatokat js változókba töltenéd le, szép nagy tömböket csinálva, aztán user oldalon js függvényekkel rendeznéd azokat olyan sorba ahogy akarod, végül pedig felépitenéd a táblázatot szintén js segitségével. aztán újrarendezésnél eldobnád a táblát, és újraépitenéd. adat törlésekor is elég egy ajax hivást küldeni, hogy ezt és ezt töröld, aztán a válasz függvényében keveszed a megfelelő sort a js tömbből, majd táblázatújraépités. szerintem járható út.

    viszont ha user elkezdi manipulálni a js-et, akkor elképzelhető bizonyos inkozisztencia a táblázat és az adatbázis között, ezért minden ajaxal beérkező adatot nagyon alaposan meg kell vizsgálni, hogy lehetséges-e
    Mutasd a teljes hozzászólást!
  • Hali,

    Van egy saját fejlesztésű kis admin felületem az egyik projektemnél. Jelenleg egy szép nagy sql táblát lekérdezek és beledobálom egy táblázatba (html).

    Vannak rendező és szűrőgombok, melyekkel nyilván újratöltődésnél az sql select-be küldenek infót, ez által más lesz a lekérdezés.

    Gondolkodtam azon, hogy átálljak AJAX alapú táblázat-rendezésre, szűrésre.

    A problémám elvi jellegű és tanácsokat várnék. Lehetséges, hogy csak én nem gondolok a megfelelő, másoknál tökéletesen működő útra, nem tudom.

    A probléma:
    - a lapújratöltődés lassú folyamat -> jó lenne AJAX-osan megoldani
    - igen ám, de alaphelyzetben mindenféle szűrő nélkül a tábla 2000 rekordja töltődik be, és közben PHP-val ott még alakítgatni is kell az adatokon -> kipróbáltam az egyik AJAX framework-öt és 2k rekordot hoszabb ideig tölt, mintha a jelenlegi régi megoldást alkalmaznám...
    - gondoltam, hogy darabolni kellene, pl 200-anként újratöltődés, közben AJAX -> ez sem korrekt megoldás, hiszen minden AJAX rendezésnél (ha nincsen szűrő) a teljes tábla adatai kellenek, ergó sql lekérés megint és betölteni minden adatot...

    Szóval igazából a gondom az, hogy nekem űgy tűnik sok adatnál és sok programozott résznél az AJAX még lassabb lett.
    Élek viszont a gyanúperrel, hogy én vagyok a hülye és rossz az elképzelésem, meg rosszul próbálkoztam.

    Van esetleg vki, aki szokott nagyobb táblákat AJAX-al rendezgetni, akinek van tapasztalat, hogy hogyan érdemes összehangolni ezeket?

    Előre is köszi a válaszokat.
    K
    Mutasd a teljes hozzászólást!
abcd