SQL: vypis susedov

[BlackMagic]

Když už ukládat do cache, tak spíš víc stránek, třeba 5. Pak by se nové do cache načítaly. jen když uživatel přejde na hraniční stránku.

(Anebo tlačítko Načíst další a připojit další sadu na konec tabulky - na vyžádání, ne infinite scrolling)

[Reklama]

[Ivan Brezina]

Vim ze je to nevyzadana rada, ale strankovani je spatne z mnoha duvodu. Vykon databaze je jen z nich.
Mnohem lepsi a modernejsi pristup je "inifine scolling". Je to mnohem jednodusi a pro uzivatele je to i prehlednejsi.

[speculatius]

Udržiavať si stav na backende asi nie je riešenie. Predpokladám, že stránkovanie môže vracať rôzne výsledky v závislosti od nastavenia filtrov a zoradenia. Teda jeden používateľ môže mať otvorených viac tabov a v každom vidieť inak stránkované záznamy. Takže z pohľadu backendu by to malo byť stateless.

Udržovat si stav na backendu je řešení. Věci jako session už byly vynalezeny. Každá záložka v prohlížeči si může pamatovat identifikátor své sady záznamů uložené na serveru.

Session je jedna pre všetky taby. Implementuje sa ako ID-čko uložené v cookies, a cookies sú naviazané na adresu webu, nie na tab. Alebo máte na mysli nejakú inú formu session?

Vytiahnuť si susedov hneď s daným záznamom tiež nerieši problém úplne. Ako poznamenal Zdeno Sekerák vyššie, len po posunie problém o krok (n-krokov) ďalej.

Řeší to problém úplně, protože při přechodu na jinou stránku a pošle požadavek na server a načte se nová trojice.

Práve ste povedali, že pri prechode sa načíta nová trojica => musí sa nanovo spustiť stránkovacia query. Tomu sa predsa OP chce vyhnúť, to je podstata tejto diskusie.

[Kit]

Práve ste povedali, že pri prechode sa načíta nová trojica => musí sa nanovo spustiť stránkovacia query. Tomu sa predsa OP chce vyhnúť, to je podstata tejto diskusie.

Není mi jasné, proč se chce vyhnout opětovnému dotazu do databáze. Podle mne je to nejefektivnějším řešením.

[BlackMagic]

Jediný dotaz stačí, když načte všechno, pošle to do prohlížeče a ta čísla [1,2,3,4,5,6,7,8,10..] budou přepínat taby ...

[Reklama]

[Filip Jirsák]

Session je jedna pre všetky taby. Implementuje sa ako ID-čko uložené v cookies, a cookies sú naviazané na adresu webu, nie na tab. Alebo máte na mysli nejakú inú formu session?

Nikoli. Session jsou data uložená na serveru pod nějakým identifikátorem, přičemž identifikátor je v prohlížeči. Identifikátor session může být klidně v URL, v paměti aplikace, v Session/Local Storage, i v té cookie.

Práve ste povedali, že pri prechode sa načíta nová trojica => musí sa nanovo spustiť stránkovacia query. Tomu sa predsa OP chce vyhnúť, to je podstata tejto diskusie.

No, co chce hknmtt nevíme, protože to tají. Z původního dotazu to vypadalo spíš že nechce pouštět celý dotaz (pravděpodobně se spoustou joinů) na získání dat pro detail, když potřebuje znát pro předchozí/následující stránku jen id. A dotazy jsou pravděpodobně nějak automaticky generované a hknmtt buď neumí nebo nemůže upravit jejich generování tak, aby vracely jen id. Ale ono je to celkem jedno, hknmtt nechce vyřešit svůj problém, proto ho nepopsal, takže je to tady spíš takové nezávazné povídání o tom, co všechno se může skrývat za pojmem „stránkovaný dotaz. Přičemž je dost možné, že hknmtt o žádné stránkované dotazy nestojí, protože za stránkované dotazy se obvykle označuje něco, co velké množství záznamů zobrazuje postupně po stránkách (v databázové terminologii se tomu říká spíš okna), zatímco hknmtt psal o tom, že zobrazuje jen jeden záznam. Takže jde spíš o master–detail zobrazení, kdy chce na detailu zároveň zobrazovat odkazy ne sousední záznamy (vzhledem k masteru).

Jinak kdyby hknmtt opravdu nechtěl znovu spouštět dotaz na celou sadu záznamů (master), jediná možnost by byla zapamatovat si celý výsledek v nějaké cache a procházet tu. Protože ať uděláte to okno sebevětší, vždy se uživatel může doklikat až na konec a pak nezbyde než ten dotaz udělat znovu. Jenže to je právě problém, že my nevíme, jaký problém hknmtt řeší a proč by nechtěl provádět dotaz znovu (a který dotaz, protože u master–detail jsou dotazy dva).

[Kit]

No, co chce hknmtt nevíme, protože to tají. Z původního dotazu to vypadalo spíš že nechce pouštět celý dotaz (pravděpodobně se spoustou joinů) na získání dat pro detail, ...

Obávám se, že OP bude mít v tom dotazu ± jeden join, jinak by se o jeho složitosti zmínil.

[Pavel...]

Vim ze je to nevyzadana rada, ale strankovani je spatne z mnoha duvodu. Vykon databaze je jen z nich.
Mnohem lepsi a modernejsi pristup je "inifine scolling". Je to mnohem jednodusi a pro uzivatele je to i prehlednejsi.

hmm... ako to funguje s niecim, co je potencialne tabulka o 1000+ riadkoch?

[Filip Jirsák]

Vim ze je to nevyzadana rada, ale strankovani je spatne z mnoha duvodu. Vykon databaze je jen z nich.
Mnohem lepsi a modernejsi pristup je "inifine scolling". Je to mnohem jednodusi a pro uzivatele je to i prehlednejsi.

hmm... ako to funguje s niecim, co je potencialne tabulka o 1000+ riadkoch?

K čemu by bylo zobrazení tabulky, která má víc než 1 000 řádků? Bude to nějaký uživatel procházet očima řádek po řádku? Pokud chcete uživateli zobrazit tabulku s více než tisíci řádky, není potřeba řešit, jak mu to zobrazit, ale jak mu umožnit zadat takové filtrovací či vyhledávací podmínky, aby našel, co hledá.

[Pavel...]

K čemu by bylo zobrazení tabulky, která má víc než 1 000 řádků? Bude to nějaký uživatel procházet očima řádek po řádku? Pokud chcete uživateli zobrazit tabulku s více než tisíci řádky, není potřeba řešit, jak mu to zobrazit, ale jak mu umožnit zadat takové filtrovací či vyhledávací podmínky, aby našel, co hledá.

no ved to nechcem
z praktickeho hladiska je strankovanie jedna z praktickych moznosti ako to lahko a efektivne "filtrovat".

Predrecnik tvrdil, ze "strankovanie je zlo". Ale uz nedodal: musite zabit kopu casu a namahy pre vyrobenie velmi dobreho filtrovania, pretoze rozumny limit je povedzme 100 zaznamov.

[Ivan Brezina]

Vim ze je to nevyzadana rada, ale strankovani je spatne z mnoha duvodu. Vykon databaze je jen z nich.
Mnohem lepsi a modernejsi pristup je "inifine scolling". Je to mnohem jednodusi a pro uzivatele je to i prehlednejsi.

hmm... ako to funguje s niecim, co je potencialne tabulka o 1000+ riadkoch?

Zobrazit 1000+ radek v prohlizeci zase neni takovy problem. Otazka je jestli o to uzivatel doopravdy stoji.
U nekonecneho scrolovani mate vyhodu ze uzivateli nerikate kolik zaznamu jste nasli.

U strankovani nekde zobrazujete x/y, kde "x" je aktualni stranka a "y" je celkovy pocet stranek. Spocitat to y byva casto velmi narocne na vykon a uzivatele to casto ani nezajima. Projde jen prvnich 3-5 stranek a pak zada jiny dotaz.

U nekonecneho strankovani si zapamatujete posledni zobrazene ID a to pak pridavate do filtru where clausule:

Kód: [Vybrat]

WHERE 1=1
and ID > :last_diplayed_id
and <... dalsi podminky hledani >
FETCH FIRST 50 ROWS ONLY;

Pokud mate dobre udelane indexy, tak se pouzije INDER RANGE SCAN a databaze nemusi znovu prochazet zaznamy ktere uz byly zobrazene predchozim dotazem. To je totiz hlavni problem se strankovanim. Pro zobrazeni x-te stranky databaze musi stejne projit stranky 1 az (x-1). Ke zobrazeni celkoveho poctu stranek databaze prochazi uplne vsechny nalezene zaznamy a pak posle uzivateli jen maly vyrez dat.

[Pavel...]

Zobrazit 1000+ radek v prohlizeci zase neni takovy problem.

podla mojho pozorovania spravania prehliadacov je jednoducho to zvycajne meratelne dlho renderuje, v nejednom pripade scrollovanie laguje a tak.
Ale som ochotny uznat, ze problem je pri vacsom pocte riadkov, nikdy som si nerobil statistiku.

Otazka je jestli o to uzivatel doopravdy stoji.

samozrejme, ze nestoji
problem je na inej strane: niekedy jednoducho ma uzivatel usecase, ze potrebuje nieco na co programator nepomysel.
(ked programator pomysli, tak samozrejme uzivatel ma k dispozicii lahko pouzitelne spravne filtrovanie a nepotrebuje zobrazovat viac nez povedzme 30 zaznamov)

U strankovani nekde zobrazujete x/y, kde "x" je aktualni stranka a "y" je celkovy pocet stranek. Spocitat to y byva casto velmi narocne na vykon a uzivatele to casto ani nezajima. Projde jen prvnich 3-5 stranek a pak zada jiny dotaz.

svet nie je len nasepkavac v googli

U nekonecneho strankovani si zapamatujete posledni zobrazene ID a to pak pridavate do filtru where clausule:
...

Takze ked chcem vidiet posledny 1000ci prvok, tak mi skusate nahovorit, ze mam byt nadseny, ze budem 19x riesit problem pomaleho scrollovania (kedze zakazdym doplnite 50 zaznamov), kde  zakazdym bezi pomaly dotaz na server a do databazy? (bez ohladu na optimalizaciu, rezia je sama o sebe neprijemna)

---

ok, chapem, ze ak je gro vasej prace robenie veci ako nasepkavac, tak rozumiem, ze "nekonecne scrollovanie" je fajn.
Len na zaciatku ste sformulovali ultimatnu myslienku, ze to je vo vseobecnosti jedine spravne riesenie.
Tak ma zaujalo, nakolko prehanate.

Priklad z praxe: mam zoznam o tak 500 prvkoch, vzdy hladam jeden konkretny. Tu by ma asi uzivatelia zabili, keby som im ponukol vami preferovane riesenie.

[Filip Jirsák]

problem je na inej strane: niekedy jednoducho ma uzivatel usecase, ze potrebuje nieco na co programator nepomysel.

V takovém případě je problém v tom, že uživatelské rozhraní navrhuje programátor a ne UX designer. Ostatní jsou už jen důsledky.

Priklad z praxe: mam zoznam o tak 500 prvkoch, vzdy hladam jeden konkretny. Tu by ma asi uzivatelia zabili, keby som im ponukol vami preferovane riesenie.

V tom vašem příkladu z praxe budete zobrazovat 500 záznamů třeba po 10 na jedné stránce. Uživatel bude chtít záznam s pořadovým číslem 375 (je dost nepravděpodobné, že by věděl přesně, kde v seznamu jeho záznam je, ale dejme tomu.). Spočítá si tedy, že jeho záznam bude na stránce 37. Zobrazíte uživateli čísla stránek od 1 do 50? Nebo zobrazíte pár čísle stránek kolem aktuální stránky Nebo ho necháte číslo stránky napsat? Nebude přeci jen lepší nechat návrh uživatelského rozhraní na UX designérech? Tu aplikaci asi také neprogramují obchodníci, ale někdo, kdo rozumí programování. Stejně tak by uživatelské rozhraní měl navrhovat někdo, kdo rozumí návrhu uživatelského rozhraní.

[Pavel...]

problem je na inej strane: niekedy jednoducho ma uzivatel usecase, ze potrebuje nieco na co programator nepomysel.

V takovém případě je problém v tom, že uživatelské rozhraní navrhuje programátor a ne UX designer. Ostatní jsou už jen důsledky.

Obvykla rydzo teoreticka poznamka cloveka co nevie o com hovori.
Uz Vam to tu povedalo v roznom kontexte hrst ludi, takze chapem, ze to je hadzanie hrachu na stenu.

Priklad z praxe: mam zoznam o tak 500 prvkoch, vzdy hladam jeden konkretny. Tu by ma asi uzivatelia zabili, keby som im ponukol vami preferovane riesenie.

V tom vašem příkladu z praxe budete zobrazovat 500 záznamů třeba po 10 na jedné stránce. Uživatel bude chtít záznam s pořadovým číslem 375 (je dost nepravděpodobné, že by věděl přesně, kde v seznamu jeho záznam je, ale dejme tomu.). Spočítá si tedy, že jeho záznam bude na stránce 37. Zobrazíte uživateli čísla stránek od 1 do 50? Nebo zobrazíte pár čísle stránek kolem aktuální stránky Nebo ho necháte číslo stránky napsat? Nebude přeci jen lepší nechat návrh uživatelského rozhraní na UX designérech? Tu aplikaci asi také neprogramují obchodníci, ale někdo, kdo rozumí programování. Stejně tak by uživatelské rozhraní měl navrhovat někdo, kdo rozumí návrhu uživatelského rozhraní.

odporucam citat kontext. Predrecnik povedal o "jedinom spravnom rieseni". Nic o UX dizajneroch.

[Tomáš Crhonek]

odporucam citat kontext. Predrecnik povedal o "jedinom spravnom rieseni". Nic o UX dizajneroch.

Jenže to jediné správné řešení by měl navrhnout někdo kompetentní. Doba, kdy IT nadšenci do programovacích jazyků zobrazovali uživateli tunu informací, jen aby ukázali, že to umí, je naštěstí dávno pryč. Dneska opravdu nepotřebuju vědět, že google našel 500mil výsledků za 15ms, protože mě typicky zajímá ten první nesponzorovaný. Takže ani google ani kdokoliv jiný nemusí ve svém programu na serveru generovat půl miliardy stránek, stačí nabídnout nejlepších 100 výsledků a uživatel (já) klikne na dva.