Doporučte rychlý WWW widget pro view SQL tabulky

Re:Doporučte rychlý WWW widget pro view SQL tabulky
« Odpověď #15 kdy: 20. 05. 2021, 00:35:02 »
Já bych rozhodnutí zda zobrazovat 1000 nebo jeden řádek nechal na tazateli a jeho uživatelích. Mě šlo pouze o to, že zobrazit 1000 řádků z JSON nebo je následně filtrovat není výkonnostní problém. Rychlost jsem ilustroval na listjs a uživatelský usecase na Thunderbirdu, kde vidím v tabulce 10 tis. mailů a filtruju mezi nimi. Jiné ambice jsem v této diskuzi neměl a ani nyní nemám  :)


Re:Doporučte rychlý WWW widget pro view SQL tabulky
« Odpověď #16 kdy: 20. 05. 2021, 08:23:47 »
V případě, že na data koukají stovky různých uživatelů a nikdo předem neví, co koho zajímá, je podle mě kombinace stránkování, řazení a filtrace to pravé, co snadno uspokojí všechny bez nějakého kouzelného UI.
Pokud je dat jen tolik, aby je snadno výkonnostně zvládnul klient, není problém mu je poslat všechna a vizualizaci nechat na něm, pokud je jich více, pošle mu server jen pohled na jejich část.
- stránkování snadno naznačí s jakým množstvím dat se pracuje, aniž by se data musela všechna najednou zobrazit nebo přenáet ke klientovi, není většinou přímo určené k tomu, aby uživatel všechny stránky prohlížel, ale ve specifických případech, kdy je řazení a filtrace nedostačující, to umožní, není omezený jen na rozsah dat určený natvrdo vývojářem (třeba prvních 10 vyhovujících záznamů).
- seřazení podle vybraného sloupce v kombinaci s filtrací je podle mě to pravé co poskytne rychlý přístup ke správným datům, aniž by bylo potřeba předem něco řešit za uživatele.
Pracuju vcelku často s aplikací, kde prohlížím tabulky s desítkami tisíc záznamů a hledám v nich ty správné - obecný textový filtr přes všechny zobrazené sloupce (s našeptávačem častých filtrů i s možností specifikace filtrace jen na vybraný sloupec) v kombinaci se správným řazením záznamů je pro mě opravdu to nejrychlejší, jak najít správné záznamy - v tomhle případě vše řešené na serveru, přenášet 100 000 záznamů na klienta už je neefektivní.

Re:Doporučte rychlý WWW widget pro view SQL tabulky
« Odpověď #17 kdy: 20. 05. 2021, 09:58:48 »
V případě, že na data koukají stovky různých uživatelů a nikdo předem neví, co koho zajímá, je podle mě kombinace stránkování, řazení a filtrace to pravé, co snadno uspokojí všechny bez nějakého kouzelného UI.
Pokud je dat jen tolik, aby je snadno výkonnostně zvládnul klient, není problém mu je poslat všechna a vizualizaci nechat na něm, pokud je jich více, pošle mu server jen pohled na jejich část.
- stránkování snadno naznačí s jakým množstvím dat se pracuje, aniž by se data musela všechna najednou zobrazit nebo přenáet ke klientovi, není většinou přímo určené k tomu, aby uživatel všechny stránky prohlížel, ale ve specifických případech, kdy je řazení a filtrace nedostačující, to umožní, není omezený jen na rozsah dat určený natvrdo vývojářem (třeba prvních 10 vyhovujících záznamů).
- seřazení podle vybraného sloupce v kombinaci s filtrací je podle mě to pravé co poskytne rychlý přístup ke správným datům, aniž by bylo potřeba předem něco řešit za uživatele.
Pracuju vcelku často s aplikací, kde prohlížím tabulky s desítkami tisíc záznamů a hledám v nich ty správné - obecný textový filtr přes všechny zobrazené sloupce (s našeptávačem častých filtrů i s možností specifikace filtrace jen na vybraný sloupec) v kombinaci se správným řazením záznamů je pro mě opravdu to nejrychlejší, jak najít správné záznamy - v tomhle případě vše řešené na serveru, přenášet 100 000 záznamů na klienta už je neefektivní.
Všimněte si, že to, co jste popsal, má i technickou výhodu – nikdy nepotřebujete zobrazovat tisíc záznamů. Zobrazujete jen pár záznamů, které uživatele zajímají, případně celkový počet záznamů, který odpovídá zadaným podmínkám (takže není potřeba ani stránkování).

Nicméně to už se bavíme o UX. Ale je na tom vidět, že je dobré UX vyřešit dopředu, protože pak zjistíte, že vlastně vůbec nemusíte při vývoji řešit problém, jak uživateli zobrazit tisíc záznamů najednou.

Re:Doporučte rychlý WWW widget pro view SQL tabulky
« Odpověď #18 kdy: 20. 05. 2021, 11:41:01 »
Všimněte si, že to, co jste popsal, má i technickou výhodu – nikdy nepotřebujete zobrazovat tisíc záznamů. Zobrazujete jen pár záznamů, které uživatele zajímají, případně celkový počet záznamů, který odpovídá zadaným podmínkám (takže není potřeba ani stránkování).

Pokud se podívám na ten svůj Thunderbird, tak vidím nejprve tisíce záznamů, které rychle zúžím na počet, který mi vyhovuje (což může být i těch tisíc, pokud je třeba někam přesouvám). Je to rychlé a není to problém ani pro mne ani  pro počítač. Je to jen můj názor, nikomu ho nenutím.

Celá debata je tedy jen o tom, jaký maximální počet ještě počítač a uživatel zvládne. Ať si to uživatel klidně někde nastaví - pan Jirsák si tam dá 1 řádek a bude spokojen :D

Logik

  • *****
  • 974
    • Zobrazit profil
    • E-mail
Re:Doporučte rychlý WWW widget pro view SQL tabulky
« Odpověď #19 kdy: 20. 05. 2021, 11:59:16 »
Standa:
Koukni na react-table. Akorát je trochu drbačka s rozchozením reactu (ale na to najdeš tutoriál), ale pak to umí všechno, co IMHO budeš od visualizace tabulkových dat potřebovat (včetně dočítání dalších dat ze serveru)

Filip:
Citace
DOM opravdu nemusíte jen vyrábět JavaScriptem, můžete ho získat i nativním parsováním HTML zabudovaným v prohlížeči.
Jo, můžeš. A taky se můžeš drbat levou nohou za pravym uchem.

Výsledek je hůře udržovatelnej kód a drbačka se synchronizací stavu na klientu a serveru (posílat stav všech - často na sobě nezávislých - renderovaných komponent, je fakt žůžo), za což ovšem získáš UI s podstatně pomalejší reakcí na vstup uživatele a problémy s asynchronicitou a přerenderováváním stránky (když uživatel "zběsile kliká").
Od týdle technologie se snažej všude, kde to jde (tedy není řešení postavený na legacy frameworcích) dát ruce pryč a vědí proč. Před deseti (dvaceti?) lety to na tehdejší "jednoduchý" weby byla rozumná technologie. Ale doporučovat to někomu dneska... no radši to nebudu dál komentovat.

Citace
Ale je na tom vidět, že je dobré UX vyřešit dopředu
To je samozřejmě pravda, pokud ovšem existují předem jasně dané usecase. Což právě v případě analýzy dat není ani zdaleka pravidlem, protože dost často to, co člověk vlastně v datech hledá, se dozví až během analýzy. Např. filtrování je dobrý a řeší úplně všechno.... do tý doby, než např. zjistíš, že Tě nezajímají jen vyfiltrované položky, ale jejich okolí.

Pro tydle účely je nějakej datagrid s JS fitrováním a dynamickým dočítáním dat IMHO nejvhodnější technologie.







robin martinez

  • *****
  • 876
  • Have you hugged your toilet today?
    • Zobrazit profil
    • Null Storage
    • E-mail
Re:Doporučte rychlý WWW widget pro view SQL tabulky
« Odpověď #20 kdy: 20. 05. 2021, 13:11:00 »
tvl, uz chapu, jak vznikaji mizerni programatori :D

Ale je pravda, ze se dost casto setkavam s lidma, co jsou liny a nechteji resit strankovani, tak vyblejou na web celou databazi. Pecka
One machine can do the work of fifty ordinary men. No machine can do the work of one extraordinary man.

I do Linux, Hardware and spaghetti code in PHP, Python and JavaScript

Re:Doporučte rychlý WWW widget pro view SQL tabulky
« Odpověď #21 kdy: 20. 05. 2021, 13:42:46 »
Pokud se podívám na ten svůj Thunderbird, tak vidím nejprve tisíce záznamů
K čemu je to dobré? Pokud ten seznam e-mailů stahujete ze serveru, přenesou se ta data zbytečně, vy si pak můžete zanadávat, kolik paměti žere Thunderbird – a jinak?

Jo, můžeš. A taky se můžeš drbat levou nohou za pravym uchem.

Výsledek je hůře udržovatelnej kód a drbačka se synchronizací stavu na klientu a serveru (posílat stav všech - často na sobě nezávislých - renderovaných komponent, je fakt žůžo), za což ovšem získáš UI s podstatně pomalejší reakcí na vstup uživatele a problémy s asynchronicitou a přerenderováváním stránky (když uživatel "zběsile kliká").
Od týdle technologie se snažej všude, kde to jde (tedy není řešení postavený na legacy frameworcích) dát ruce pryč a vědí proč. Před deseti (dvaceti?) lety to na tehdejší "jednoduchý" weby byla rozumná technologie. Ale doporučovat to někomu dneska... no radši to nebudu dál komentovat.
Bavíme se o optimalizaci v případě, kdy by tazatel ověřil, že je problém opravdu v manipulaci s domem a že tam nemá nějaká zbytečná volání. To je holt nevýhoda optimalizací, že zpravidla znamenají hůže udržovatelný kód. Kdyby to šlo napsat efektivně a zároveň hezky, napíše se to tak rovnou a není potřeba to optimalizovat.

Jinak jste se rozvášnil zbytečně, já jsem psal jenom o těch datech tabulky. Jestli se uživateli zobrazuje tabulka s tisíci záznamy, a na každém řádku spousta komponent, jejichž stav může uživatel měnit, tak se nedivím, že je to pomalé. Akorát pořád nevím, co s tím bude ten uživatel dělat.


To je samozřejmě pravda, pokud ovšem existují předem jasně dané usecase. Což právě v případě analýzy dat není ani zdaleka pravidlem, protože dost často to, co člověk vlastně v datech hledá, se dozví až během analýzy.
Analýza dat je také use case. přičemž procházet ta data očima je zase ten nejméně vhodný nástroj pro analýzu dat. Pokud autoři aplikaci neumí zjistit, jak se data budou analyzovat, ať se vykašlou na zobrazení tisíců řádků ve webovém prohlížeči, což bude uživateli stejně k ničemu, a umožní mu vyexportovat ta data do Excelu. Tam už si s tím uživatel poradí mnohem lépe, než ve webové stránce bez nástrojů.

Např. filtrování je dobrý a řeší úplně všechno.... do tý doby, než např. zjistíš, že Tě nezajímají jen vyfiltrované položky, ale jejich okolí.
Zobrazení okolí filtrovaných položek není žádná magie, která by se nedala naprogramovat.

Pro tydle účely je nějakej datagrid s JS fitrováním a dynamickým dočítáním dat IMHO nejvhodnější technologie.
Pokud to někdo myslí vážně, že bude uživateli zobrazovat tisíce záznamů, je nejvhodnější technologie export do Excelu. Protože ten ty nástroje pro práci s daty má, uživatel si to tam už vyfiltruje, seřadí, seskupí a spočítá tak, jak potřebuje. Bude to podstatně užitečnější, než když to bude muset do Excelu kopírovat přes schránku (a milionkrát užitečnější, než špatně udělaný grid, ze kterého ta tabulková data nejdou přes schránku rozumně vykopírovat).





[/quote]

Re:Doporučte rychlý WWW widget pro view SQL tabulky
« Odpověď #22 kdy: 20. 05. 2021, 13:45:02 »
tvl, uz chapu, jak vznikaji mizerni programatori :D

Ale je pravda, ze se dost casto setkavam s lidma, co jsou liny a nechteji resit strankovani, tak vyblejou na web celou databazi. Pecka

nejsou lini, spis ignoranti. Strankovani je bezpracne, pokud pouzijete hotovy widget.

Logik

  • *****
  • 974
    • Zobrazit profil
    • E-mail
Re:Doporučte rychlý WWW widget pro view SQL tabulky
« Odpověď #23 kdy: 20. 05. 2021, 15:21:58 »
Citace
...a milionkrát užitečnější, než špatně udělaný grid...
Jasně. Tvoje řešení je nejlepší, protože bude udělané dobře, zatímco ostatní to udělaj blbě. Tomu říkám argument.

Jinak export do Excelu od určité velikosti záznamů má velkou nevýhodu v tom, že narozdíl od webgui Ti neumožní dotahovat další data, takže musíš vyblejt celou datbázi najednou, což je v mnoha případech (např. kdy se běžně dívá na logy z posledního dne a jen zřídka potřebuješ jít dál) zbytečné.
Citace
To je holt nevýhoda optimalizací, že zpravidla znamenají hůže udržovatelný kód. Kdyby to šlo napsat efektivně a zároveň hezky, napíše se to tak rovnou a není potřeba to optimalizovat.
A toto právě dokládá to, že "děláš chytrého" ve věci, s kterou evidentně nemáš žádné zkušenosti. Existuje x JS webových aplikací, které takový problém zvládají dobře. Tedy evidentně Tvoje "že by to tak bylo nutně napsané dobře", je nesmysl. Tazatel si prostě vybral špatnou knihovnu, nikoli špatnou technologii.

To, co tvrdíš - že optimalizace znepřehledňuje kód - je sice teoreticky pravda, ale pouze od určité úrovně. Naopak do určité úrovně správně napsaný a tedy rychlý kód je přehlednější a použitelnější, než "bastl". A to, co řeší tazatel, se ani náhodou neblíží k limitu, kdy by to dobře napsaná webgui aplikace nezvládla. A navíc je to právě naopak, dobře napsaná JS aplikace má ty limity v některých ohledech podstatně dál, než aplikace která tahá ze serveru vygenerované html snapshoty. Z mnoha důvodů, např. že podstatně snáz se tam dělá cache a znovupoužití dotažených záznamů ze serveru.
Tvoje rada je podobnej nesmysl, jako svého času byly na webu zaručené rady, že používat JOINY je špatně, protože jsou pomalé. Což byla pravda.... pokud znal člověk jen MySQL a neuměl používat pořádný databáze. Pak ano, pak bylo lepší používat nástroje z doby krále klacka. Tvoje rada tazateli je "z podobného ranku".

Citace
Jinak jste se rozvášnil zbytečně, já jsem psal jenom o těch datech tabulky
Takže ještě budeš kombinovat dvě různé technologie a lepit je na sebe - a jako myslíš si, že tím vznikne rychlejší a nebo přehlednější kód. Hele, sorry, fakt je vidět, že mluvíš o věci, o který sis možná někdy něco přečet, ale zkušenosti s tím nemáš....


Re:Doporučte rychlý WWW widget pro view SQL tabulky
« Odpověď #24 kdy: 20. 05. 2021, 16:51:33 »
Citace
...a milionkrát užitečnější, než špatně udělaný grid...
Jasně. Tvoje řešení je nejlepší, protože bude udělané dobře, zatímco ostatní to udělaj blbě. Tomu říkám argument.
Já jsem nepsal nic o tom, jestli je něco moje řešení nebo řešení někoho jiného. Tomu, co jste ředvedl, se říká slaměný panák.

Existuje x JS webových aplikací, které takový problém zvládají dobře.
Zvládají to technicky dobře, ne dobře z hlediska UX. Bohužel pro vás tohle tvrzení není v rozporu s ničím, co jsem napsal, takže vaše teorie o tom, že s tím nemám zkušenosti, jsou jen další vaše demagogie.

To, co tvrdíš - že optimalizace znepřehledňuje kód - je sice teoreticky pravda, ale pouze od určité úrovně. Naopak do určité úrovně správně napsaný a tedy rychlý kód je přehlednější a použitelnější, než "bastl".
Děkuji za potvrzení mého tvrzení, že optimalizace znamená, že správně napsaný a přehledný kód v zájmu vyšší rychlosti nebo menší paměťové náročnosti přepíšu a bohužel ho při tom musím znepřehlednit. Pokud je nějaký kód napsaný špatně a já ho přepíšu, aby byl srozumitelný, a přitom se ten kód jako vedlejší efekt i zrychlí, není to optimalizace, ale obyčejná oprava špatně napsaného kódu.

A to, co řeší tazatel, se ani náhodou neblíží k limitu, kdy by to dobře napsaná webgui aplikace nezvládla.
Tazatele zřejmě řešení nezajímá, takže jsme se nedozvěděli, jak přesně ta tabulka vypadá. Je možné, že v těch tisíci řádcích opravdu je spousta interaktivních komponent – sice to z hlediska UX nedává žádný smysl, ale to nedává ani těch 1000 řádků. Výpis takové tabulky by samozřejmě trval dlouho, klidně je možné i se správným kódem se dostat na ty časy, které uváděl tazatel. Takovou tabulku (se zachováním funkčnosti) ovem moc optimalizovat nejde. Jediné, kde se ten problém dá řešit, je UX. Takže stále platí to, co jsem psal na začátku. Pokud se ten problém má opravdu vyřešit, je potřeba se zaměřit na UX. Až se vyřeší UX, technický problém nejspíš zmizí.

A navíc je to právě naopak, dobře napsaná JS aplikace má ty limity v některých ohledech podstatně dál, než aplikace která tahá ze serveru vygenerované html snapshoty. Z mnoha důvodů, např. že podstatně snáz se tam dělá cache a znovupoužití dotažených záznamů ze serveru.
Preo vás je možná limitem to, co se dělá snadno. Já mám limity dál a klidně se pustím i do věcí, které jsou obtížné.

Tvoje rada je podobnej nesmysl, jako svého času byly na webu zaručené rady, že používat JOINY je špatně, protože jsou pomalé.
Další slaměný panák.

Takže ještě budeš kombinovat dvě různé technologie a lepit je na sebe - a jako myslíš si, že tím vznikne rychlejší a nebo přehlednější kód. Hele, sorry, fakt je vidět, že mluvíš o věci, o který sis možná někdy něco přečet, ale zkušenosti s tím nemáš....
Optimalizace se nedělá proto, aby vznikl přehlednější kód. Právě naopak, optimalizace znamená, že se obětuje přehlednost v zájmu vyšší efektivity kódu. Zkuste to pochopit.

Jinak pro vaši informaci, parsování HTML prohlížečem do DOMu je podstatně rychlejší, než když parsujete JSON a pak z něj v JavaScriptu vyrábíte DOM. Proto jsou poslední dobou tak v oblibě generátory statických webů postavené na frontendových technologiích jako Gatsby, Next.js, Gridsome, Sapper apod. Ale můžete všem, kteří to používají kvůli rychlosti výsledného webu, vysvětlit, že vy jste ten odborník, a že to všichni dělají špatně, je to pro uživatele pomalé, a navíc se jim to bude strašně špatně vyvíjet, nemohou používat cache…

Logik

  • *****
  • 974
    • Zobrazit profil
    • E-mail
Re:Doporučte rychlý WWW widget pro view SQL tabulky
« Odpověď #25 kdy: 20. 05. 2021, 18:38:15 »
Filip:
To, proč je Tebou navrhovaný přístup dle mého názoru špatně, proč navrhovaná technologie IMHO není vhodná, a proč IMHO volba kvalitního webového JS gridu je dobrý způsob řešení toho problému jsem již napsal. To je pro tazatele podstatná informace, a k tomu nemám co dodat ani co doplnit.

Nic z toho, čím jsi na to reagoval to nijak nevyvrací - jen jsi buďto nepochopil, co jsem se Ti snažil sdělit, nebo to úmyslně překroutil. A protože to není poprve, tak sorry, ale do další nesmyslné diskuse se vtáhnout nenechám.




Kit

  • *****
  • 644
    • Zobrazit profil
    • E-mail
Re:Doporučte rychlý WWW widget pro view SQL tabulky
« Odpověď #26 kdy: 20. 05. 2021, 19:13:38 »
Pokud se html generuje na klientovi a interakce s ui je také řešena na klientovi, ušetří se výpočetní výkon serveru který je pak k dispozici pro obsluhu dalších požadavků. Část výpočetního výkonu se tedy distribuuje mezi klienty. Data se ze serveru přenáší typicky pomocí JSON. Co k tomu víc dodat?
Ten JSON se podle vás vezme kde? Nebo myslíte, že když bude server generovat {"jmeno": "Jiří Novák"} místo <td>Jiří Novák</td>, ušetří se tím nějak výrazně jeho výkon?

Docela výrazně - generování JSON spotřebuje asi jednu desetinu výkonu oproti HTML. Navíc je zbytečné renderovat HTML i na klientovi, takže klient ho nemusí ani parsovat.

Re:Doporučte rychlý WWW widget pro view SQL tabulky
« Odpověď #27 kdy: 20. 05. 2021, 19:14:56 »
Dobrý způsob řešení je nezobrazovat tisíciřádkovou tabulku.

Když se teda budeme bavit o tom, jak technicky řešit zobrazení takové tabulky. Použití kvalitního webového JS gridu by bylo dobré řešení, když to bude „na zelené louce“, nebude tam nic okolo. Jenže tazatel už tam JS framework má, cpát do toho nekompatibilní grid může být problematické. Doručit tam rovnou statické HTML může být bezpečnější. Které řešení je lepší tady nerozhodneme, když nevíme detaily. Ale jak jsem psal, důležitější je vyřešit UX, technický problém se tím nejspíš vyřeší sám.

Re:Doporučte rychlý WWW widget pro view SQL tabulky
« Odpověď #28 kdy: 20. 05. 2021, 19:17:16 »
Docela výrazně - generování JSON spotřebuje asi jednu desetinu výkonu oproti HTML.
Jo, ty špičaté závorky se v tom procesoru zasekávají, složené projdou mnohem líp… Na tohle se fakt nedá nic jiného napsat…

Navíc je zbytečné renderovat HTML i na klientovi, takže klient ho nemusí ani parsovat.
Nějak mi uniká, co jste touhle větou chtěl říct.

Pixe

Re:Doporučte rychlý WWW widget pro view SQL tabulky
« Odpověď #29 kdy: 20. 05. 2021, 19:23:49 »
Necháme kluky ať se vydiskutují a mezitím se vrátíme k tématu. Jakým způsobem ta data to té komponenty láduješ? Používáš ten LazyDataModel? Nemáš například volání repository v get metodě? Přímo v dokumentaci je ukázka pro 20k záznamů, takže pokud tam někde nepácháš nějaké harakiri, tak by to ta knihovna měla pobrat

http://primefaces.org/showcase/ui/data/datatable/scroll.xhtml?jfwid=046d1


...
Problem mi nastal, kdyz se pokousim ty data vizualizovat na webu, obvykle pouzivam JSF2 widget Primefaces::Datatable s paginaci, zatim jsem pouzival paginaci cca 30 radku, tam to funguje skvele.
Nyni potrebuju paginaci radove 1000 zobrazenych radku (nebo uplne bez paginace), a tam mi pri paginaci 1000 radku trvalo robrazeni Primefaces Datatable pres minutu.
« Poslední změna: 20. 05. 2021, 19:25:56 od Pixe »