Řádkový filtr v HELIOS Green je podle mě opravdu povedený.
Jednoduchý, intuitivní a přitom hodně možností.
2 komentáře: “Helios Green – Video řádkový filtr (uživatel)”
Dobrý den, chci se zeptat, zda je tento filtr použitelný i na větším objemu dat a tabulkách s větším obsahem sloupců? Tedy řekněme alespoň 20 sloupců a minimálně 1 mil. záznamů. Pokud ano, můžete prosím případně doplnit i toto video, případně budu rád za informaci, jak jsou potom dlouhé časové prodlevy při načítání takového seznamu a při hledání v něm.
Děkuji
S pozdravem
Marek Hejna
Filtr je podle mě rozhodně použitelný i na větším množství záznamů i sloupců.
Nicméně hodně záleží
1. Na rychlosti SQL serveru. Helios nedělá v postatě nic jiného než že dá do selectu podmínku:
WHERE (lcs.organizace.cislo_poradace = 50) AND ((lcs.organizace.poznamka LIKE ‚%test%‘))
2. Jak je udělaný přehled (třídění, sloupce dělané výpočtem = subselecty) apod.
3. Co se vyhledává (selectivita)
4. Jak často se vyhledává přes ten sloupec
5. atd.
Sloupce nemusí být nijak naindexované (jako je zvykem u jiných ERP), uživatel si maximálně počká.
Což může být i problém, uživatelé někdy pouštějí selecty trvající desítky minut.
Správce nicméně může rychlosti pomoct vytvořením indexu (sám jsem jich přidával už asi dvacet).
Konkrétní případy:
* Půl miliónu organizací, vyhledání dle názvu. Trvá cca 4 sekundy. Pokud je vyhledávaný krátký řetězec tak se prodlouží na 11s, pokud je delší, vyhledává se na začíná, nikoli obsahuje, jsou to tak 2 sekundy.
* Dtto vyhledání dle poznámky (varchar (max)). Znatelně pomalejší, není nad ní index. První vyhledání (jakéhokoli uživatele) trvá přes minutu (nevyužije se cache, na poznámku se standardně nefiltruje), další vyhledávání pak cca 35s, a pak podle toho co se hledá jsou výsledky 35s, 11s apod.
*3,5mil uživatelská třída, filtrování na textový údaj varchar(100) podřetězec. první vyhledání cca 75s, další hledání 14s, 35s podle toho co se hledá.
2 komentáře: “Helios Green – Video řádkový filtr (uživatel)”
Dobrý den, chci se zeptat, zda je tento filtr použitelný i na větším objemu dat a tabulkách s větším obsahem sloupců? Tedy řekněme alespoň 20 sloupců a minimálně 1 mil. záznamů. Pokud ano, můžete prosím případně doplnit i toto video, případně budu rád za informaci, jak jsou potom dlouhé časové prodlevy při načítání takového seznamu a při hledání v něm.
Děkuji
S pozdravem
Marek Hejna
Filtr je podle mě rozhodně použitelný i na větším množství záznamů i sloupců.
Nicméně hodně záleží
1. Na rychlosti SQL serveru. Helios nedělá v postatě nic jiného než že dá do selectu podmínku:
WHERE (lcs.organizace.cislo_poradace = 50) AND ((lcs.organizace.poznamka LIKE ‚%test%‘))
2. Jak je udělaný přehled (třídění, sloupce dělané výpočtem = subselecty) apod.
3. Co se vyhledává (selectivita)
4. Jak často se vyhledává přes ten sloupec
5. atd.
Sloupce nemusí být nijak naindexované (jako je zvykem u jiných ERP), uživatel si maximálně počká.
Což může být i problém, uživatelé někdy pouštějí selecty trvající desítky minut.
Správce nicméně může rychlosti pomoct vytvořením indexu (sám jsem jich přidával už asi dvacet).
Konkrétní případy:
* Půl miliónu organizací, vyhledání dle názvu. Trvá cca 4 sekundy. Pokud je vyhledávaný krátký řetězec tak se prodlouží na 11s, pokud je delší, vyhledává se na začíná, nikoli obsahuje, jsou to tak 2 sekundy.
* Dtto vyhledání dle poznámky (varchar (max)). Znatelně pomalejší, není nad ní index. První vyhledání (jakéhokoli uživatele) trvá přes minutu (nevyužije se cache, na poznámku se standardně nefiltruje), další vyhledávání pak cca 35s, a pak podle toho co se hledá jsou výsledky 35s, 11s apod.
*3,5mil uživatelská třída, filtrování na textový údaj varchar(100) podřetězec. první vyhledání cca 75s, další hledání 14s, 35s podle toho co se hledá.