MySQL - podmíněný SELECT přes dvě tabulky

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #210 kdy: 25. 10. 2019, 09:28:49 »
Už výše bylo řečeno, že součástí toho klíče je i interní ID záznamu, které nemůže být duplicitní.
Podle tohoto popisu není v PostgreSQL ID záznamu součástí klíče, ale je ve stromu uložené jako hodnota, na kterou se ten klíč odkazuje. Z čeho usuzujete na opak?

Takže to má jinak a připouští duplicitu klíče, viz klíč '49'. Jak by z tohoto měl jít udělat distinct jinak, než poctivým traverzováním?

Já si myslím, že Filip hovoří o databázích, u kterých je (možná?) full table scan jednoho sloupce pomalejší, než totožné projití stejného počtu záznamů v indexu. Je to možné?


Kit

  • *****
  • 704
    • Zobrazit profil
    • E-mail
Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #211 kdy: 25. 10. 2019, 09:56:47 »
Už výše bylo řečeno, že součástí toho klíče je i interní ID záznamu, které nemůže být duplicitní.
Podle tohoto popisu není v PostgreSQL ID záznamu součástí klíče, ale je ve stromu uložené jako hodnota, na kterou se ten klíč odkazuje. Z čeho usuzujete na opak?

Takže to má jinak a připouští duplicitu klíče, viz klíč '49'. Jak by z tohoto měl jít udělat distinct jinak, než poctivým traverzováním?

Já si myslím, že Filip hovoří o databázích, u kterých je (možná?) full table scan jednoho sloupce pomalejší, než totožné projití stejného počtu záznamů v indexu. Je to možné?

Možné to je, dokonce se to může dynamicky měnit i v průběhu života jedné tabulky.

Logik

  • *****
  • 1 022
    • Zobrazit profil
    • E-mail
Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #212 kdy: 25. 10. 2019, 10:43:04 »
Citace
Našeptávání je jediná reálná úloha, kdy uživatel pracuje se seznamem štítků.
1) Ano - jak jinak vybruslit z toho, že něco neumíš, než prohlásit, že to není potřeba, že?
2) V minulém mailu jsem asi potřetí zopakoval usecase, na který je potřeba mít seznam všech štítků - ten usecase se reálně používá (mohu doložit). Jaká je Tvá reakce? Aniž bys ten usecase jakkoli rozporoval, tak napíšeš, todle.
Tak nevím - Tvůj mozek automaticky ignoruje to, co se Ti nehodí do krámu a ani jsi to doteď nezaznamenal? Anebo o tom usecase víš, a jen se snažíš prosadit svoje stylem: když to mnohokrát zopakuji, stane se z toho pravda?
Seznam štítků je třeba pravidelně revidovat, protože jinak i v nejgeniálněji napsaném systému dřív nebo pozdějc někdo založí štítky
 "novikny", "novinka" "novynka".... A pokud navrhuješ procesy tak, že se na takovéto chyby, které nutně vznikají v každém systému, dá přijít jen náhodou, a není způsob, jak na ně přijít pravidelnou systémovou revizí dat, tak opět potěš koště. Anebo budeš revidovat štítky tak, že budeš revidovat ty tísíce záznamů štítky používající? To taky potěš koště...

3) Řešili jsme konkrétní zadání. V minulých postech jsi se šíleně čertil, když jsme zadání jen implementovali tak, že to připouštělo jeho změnu. A najednou tady prohlásíš to, že sice v zadání je A, ale to přeci uživatel nepotřebuje, takže já mu napíšu B. Zlobil ses, když jsme přemešleli nad tím, zda není třeba vozit kromě lidí i uhlí. A teď vůbec lidi vozit nebudeš, protože umíš vozit jen uhlí. Fakt Ti to není trapný?

4) I to našeptávání v tvém případě bude pomalé, ať už použiješ např. v Postrgresu BTREE index, nebo na to znásilníš GIN/GIST indexy. Prostě se smiř s tím, že indexy na tento typ úlohy nejsou dělané - PRÁVĚ PROTO, ŽE V DOBŘE NAVRŽENÉ DATABÁZI JSOU NORMALIZOVANÁ DATA A BĚŽNĚ TO NENÍ POTŘEBA.
Citace
Až na to, že spellchecker je něco úplně jiného, než stemmer. Spellchecker je prostý dotaz „existuje toto slovo?“, případně vylepšený o „pokud neexistuje, jaká podobná slova existují?“. Stemmer je nalezení kořene slova.
Opět rádobyzasvěceně hovořít o něčem, co jsi evidentně viděl jen z rychlíku. V realitě jsou spellcheck algoritmy implementovány nikoli pomocí seznamu slov, ale pomocí generativních gramatik. A kupodivu ty gramatiky jsou přesně ty samé, co se používají na stemming, a jde o stejnou úlohu - slovo projde spellcheckerem, pokud lze najít v "gramatice daného jazyka" (hunspell slovníku) kořen.

Samozřejmě, u spellcheckeru je kromě toho ještě user define seznam výjimek, ale to není nic technologicky zajímavého, ten už bude implementován pomocí klasického indexu - a s fulltextem (jak jsi předtím psal) to nesouvisí ani náhodou.

Citace
Když píšete o implementaci nějakého konkrétního databázového enginu, konkrétně ho pojmenujte.
Víš, my nejsme teoretici, co evidentně v DB toho moc nenaprogramovali, a jen mají nějaké povědomí o tom, že by "něco mělo jít". Samozřejmě, počítač je turingovsky úplnej, takže pokud takovej algoritmus umí člověk navrhnout - a to evidentně umí, když jsme Ti už dávno předestřeli řešení, které to umí - jde to zalgoritmizovat. Takže otázka kupodivu není: "je teoreticky možné, aby to databáze uměla", ale "umí to reálné databáze"?

Debata tu není o teoretických možnostech obskurní databáze z alternativní reality, ale o tom, jak se mají navrhovat DB struktury, aby to pokud možno fungovalo v každé DB, anebo alespoň v těch rozumných. A zrovna neakceleraci distinct indexem má jak postgres, tak oracle, tak MSSQL....

Tvoje argumentace, že by to nějaká DB umět mohla. Ano, mohla. A nějaká DB by mohla automaticky dělat vývojářum zmrzlinu. To nic nemění na tom, že to přinejemenším zpravidla neumí a tedy Tvé řešení je antipattern, který by se neměl doporučovat.

Citace
Jenom jestli to ví třeba Google, že vyhledávání slova ve fulltextovém indexu závisí na celkovém počtu dokumentů a ne na počtu různých slov v indexu.
Bavíme se o implementaci v relační databázi. Demonstrovali jsme Ti, že běžnou technikou v postgresu to, co tvrdíš, prostě nejde. Tak jsou dvě možnosti: BUĎTO UKAŽ NA KONKRÉTNÍM ŘEŠENÍ V ROZUMNÉ DATABÁZI, ŽE TO JDE a ukaž nám, jak použít fulltext index na akceleraci výpisu šítků, anebo i jen na to tvoje našeptávání ANEBO PŘESTAŇ ŠÍŘIT BLUDY.
To, že možná někde existuje algoritmus, který by Tvoji strukturu zvládal, je samozřejmě možné. Může Ti databáze dělat zmrzlinu. Až nějakou takovou najdeš, tak nám o ní řekni (i když teď když bude zima bych radši horkou čokoládu).
===

A Btw - ony good practices mají smysl. Uvědom si, kolik by si již při vývoji ztratil času - když sis vymyslel svoje "úžasné řešení", a teď zjišťoval, že ale vlastně B-Tree indexem to nejde indexovat. Takže fulltextem.... hmmmm, takže založíme TSVector sloupec a zkusíme. Nejde, tak ale ono to musí jít, tak jdeme googlovat.... googlím.... googlím, ale ono to přeci MUSÍ jít....

Dobrej junior používá osvědčená řešení. Dobrej senior je schopen použít originální správná řešení, když ty osvědčená se z nějakého důvodu nehodí. Ale junior, který bez znalosti problematiky se vrhá do neprozkoumaných vod (mýdlo, z odpadků, ale skvost) je k nezaplacení (rozumněj, vyjde firmu pěkně draho).

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #213 kdy: 25. 10. 2019, 11:15:59 »
...

Pane kolego, tohle je zbytečná ztráta energie a snad i emocí. Správné postupy i argumenty jsme předložili, několikrát vysvětlili, že nováčkům se mají dávat prozíravé rady. Není účelem přesvědčit Filipa - ostatně se zdá, že je mimo jeho moc diskutovat jinak, než zastávat svoji pravdu. Točit se dokola opakováním opravdu nemá smysl, stejně to beztak kromě nás čtyř nikdo nečte.

Ve Filipových argumentech jsou opravdu veletoče - jinou metrikou hodnotí své argumenty a jinou cizí. Když už je v úzkých napíše něco ve smyslu "měl byste uvést konkrétní databáze" - aniž by sám takto postupoval. Jako příklad dává databázi, na které to jednoznačně nejde, navíc se sloupcem štítků "NOT NULL", ačkoliv později označuje patřičné indexy za "nestandardní implementaci" atd.

Mrzí mě, že z této diskuse si Racchek nemůže nic smysluplného odnést.

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #214 kdy: 25. 10. 2019, 14:55:27 »
Takže to má jinak a připouští duplicitu klíče, viz klíč '49'. Jak by z tohoto měl jít udělat distinct jinak, než poctivým traverzováním?
Myslím, že není potřeba diskusi zacyklovat. Už se to tu řešilo.

2) V minulém mailu jsem asi potřetí zopakoval usecase, na který je potřeba mít seznam všech štítků - ten usecase se reálně používá (mohu doložit). Jaká je Tvá reakce? Aniž bys ten usecase jakkoli rozporoval, tak napíšeš, todle.
To je usecase „aplikace něco neumí, je potřeba dát všechna data k dispozici uživateli, aby si to vyřešil v jiné aplikaci nebo ručně“. O tom už jsem psal, jako řešení jsem navrhoval napsat aplikaci, která bude řešit skutečné požadavky uživatele.

Seznam štítků je třeba pravidelně revidovat, protože jinak i v nejgeniálněji napsaném systému dřív nebo pozdějc někdo založí štítky
 "novikny", "novinka" "novynka"....
Výborně, zadání máte, Tak si teď zkuste odpovědět na otázku: Kdo bude lepší v hledání duplicit ve stovkách štítků? Člověk, který bude číst jeden štítek za druhým, nebo počítač, který udělá podobnostní vyhledávání a nabídne uživateli: „Štítky novinky, novikny, novinka a novynka jsou podobné, chcete některé sloučit?“ Mimochodem, když pro přiřazování štítků použijete našeptávač, těchto případů bude existovat minimum, a nejspíš je někdo opraví daleko dřív, než by se k tomu dostal nějaký správce.

Prostě se smiř s tím, že indexy na tento typ úlohy nejsou dělané
Indexy na tento typ úlohy jsou dělané. Např. Lucene (NoSQL databáze pro fulltext) má speciální operátor „vrať mi všechny unikátní hodnoty daného atributu“. Ten operátor opravdu neposkytují proto, že by to byl snadný způsob, jak zatížit databázi. Poskytují ho proto, že je to často požadovaná funkce a je velmi snadné nad používaným indexem to implementovat.

V realitě jsou spellcheck algoritmy implementovány nikoli pomocí seznamu slov, ale pomocí generativních gramatik.
Ano, to je jedna z možných implementací. Ovšem co má společného s indexy? Vůbec nic. Takže jsem logicky psal o té další možné implementaci, kterou ve skutečnosti používá každý spellchecker, minimálně pro uživatelský slovník – o podobnostním vyhledávání v seznamu slov.

Víš, my nejsme teoretici, co evidentně v DB toho moc nenaprogramovali
No, pokud to programujete tak, že uživateli neposkytnete našeptávač štítků, protože ho neumíte udělat, a místo toho nutíte admina, aby se jednou za měsíc vypsal nestránkovaný seznam všech štítků a ručně tam hledal duplicity, pak upřímně lituju uživatele vašich aplikací.

Tvoje argumentace, že by to nějaká DB umět mohla.
Na argument Miroslava Šilhavého „nejde to“ je to validní protiargument. Pokud mi někdo bude argumentovat tím, že našeptávání štítků v aplikaci neudělá, protože to jeho databáze neumí, budu hledat jiný nástroj, který to umí. V tomto případě to dokonce bude ještě jednodušší, stačí dotyčnému vysvětlit, že ty databáze to umí, akorát musí použít správný typ indexu.

A Btw - ony good practices mají smysl. Uvědom si, kolik by si již při vývoji ztratil času - když sis vymyslel svoje "úžasné řešení", a teď zjišťoval, že ale vlastně B-Tree indexem to nejde indexovat.
Já jsem to nenavrhoval jako úžasné řešení, napsal jsem to jako příklad, který někdy může dávat smysl. Nepsal jsem nic takového, že to většinou bude nejlepší řešení, že to je best practice pro implementaci štítků, nic takového. Dostali jsem se k tomu v debatě o tom, jestli má JOIN popisovat strukturu získávaných dat, nebo jestli má kopírovat strukturu tabulek. Jenže místo abyste se drželi tématu debaty, tohle byla vítaná záminka jak odvést debatu jinam.

Mimochodem, s použitím B-Tree indexu pro indexování štítků jsem nepřišel já, ale vy. Já jsem jenom ukázal, že i ten B-Tree index pomůže i v té hloupé implementaci, kdy chcete seznam všech štítků, pokud ten seznam budete alespoň stránkovat. Ale vy trváte na tom, že když už uživatel musí používat vaši hloupou aplikaci, ať si to vyžere až do dna.

BUĎTO UKAŽ NA KONKRÉTNÍM ŘEŠENÍ V ROZUMNÉ DATABÁZI, ŽE TO JDE a ukaž nám, jak použít fulltext index na akceleraci výpisu šítků, anebo i jen na to tvoje našeptávání ANEBO PŘESTAŇ ŠÍŘIT BLUDY.
Nevím, jestli pořád ještě trváte na relační databázi. Tip pro to, jak vytvořit našeptávač se Solr (nadstavba nad Lucene) najdete třeba zde. Relační databáze jsou ve vyhledávání textu tradičně slabší, ale dnes už většinou mají použitelné fulltextové indexy, které se na to dají použít. Zvlášť když štítků nejspíš budou stovky a ne desítky milionů.

Dobrej junior používá osvědčená řešení. Dobrej senior je schopen použít originální správná řešení, když ty osvědčená se z nějakého důvodu nehodí. Ale junior, který bez znalosti problematiky se vrhá do neprozkoumaných vod (mýdlo, z odpadků, ale skvost) je k nezaplacení (rozumněj, vyjde firmu pěkně draho).
Jenže v této diskusi je jiný problém. Že se někdo tváří jako expert, ale juniorovi doporučuje velmi nestandardní řešení – např. INNER JOIN psát pomocí OUTER JOINu + spojovací podmínky do WHERE (kterou navíc napíše špatně). Nebo se jako úplně normální prezentuje vypsat uživateli nestránkovaný seznam všech štítků, ať si v nich hledá duplicity očima.



Kit

  • *****
  • 704
    • Zobrazit profil
    • E-mail
Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #215 kdy: 25. 10. 2019, 15:09:21 »
Víš, my nejsme teoretici, co evidentně v DB toho moc nenaprogramovali
No, pokud to programujete tak, že uživateli neposkytnete našeptávač štítků, protože ho neumíte udělat, a místo toho nutíte admina, aby se jednou za měsíc vypsal nestránkovaný seznam všech štítků a ručně tam hledal duplicity, pak upřímně lituju uživatele vašich aplikací.

My ale umíme udělat našeptávač štítků. Jen k tomu nepoužíváme indexy do obřích tabulek, protože víme, že by to bylo zoufale neefektivní a uživatel by mezitím mohl usnout.

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #216 kdy: 25. 10. 2019, 16:53:44 »
Jenže v této diskusi je jiný problém. Že se někdo tváří jako expert, ale juniorovi doporučuje velmi nestandardní řešení – např. INNER JOIN psát pomocí OUTER JOINu + spojovací podmínky do WHERE (kterou navíc napíše špatně). Nebo se jako úplně normální prezentuje vypsat uživateli nestránkovaný seznam všech štítků, ať si v nich hledá duplicity očima.

INNER JOIN už Vám byl vyvrácen vícekrát, nemá smysl se k němu vracet.

Štítky pomocí DISTINCT nad velkou tabulí jsou blbina. Tímto vzorem zrychlíte zápis a update štítku na záznamu (což jsou operace méně používané), ale zpomalíte jakékoliv dohledání (což je častější operace).

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #217 kdy: 25. 10. 2019, 19:12:09 »
My ale umíme udělat našeptávač štítků. Jen k tomu nepoužíváme indexy do obřích tabulek, protože víme, že by to bylo zoufale neefektivní a uživatel by mezitím mohl usnout.
Google má vyhledávač a má v něm i našeptávač. Buď je to zoufale neefektivní a uživatelé u toho usínají, nebo nemá zaindexováno moc dokumentů, nebo používá nějakou jinou zázračnou metodu, než indexy. A nebo neplatí váš předpoklad efektivita správného indexu pro fulltextové vyhledávání není tolik citlivá na počet zaindexovaných dokumentů/záznamů.

INNER JOIN už Vám byl vyvrácen vícekrát, nemá smysl se k němu vracet.
OUTER JOIN už vám byl vyvrácen vícekrát, nemá smysl se k němu vracet.

Jinak celá ta debata kolem nadřízených a štítků vznikla tím, že jste měl uvést příklad, kdy je podle vás správné použít INNER JOIN – a jaké je to pravidlo pro použití. Zatím jste neuvedl nic, takže to zatím vypadá, že se autoři SQL standardu zbláznili a jako default vybrali něco, co nemá žádné rozumné použití.

Štítky pomocí DISTINCT nad velkou tabulí jsou blbina. Tímto vzorem zrychlíte zápis a update štítku na záznamu (což jsou operace méně používané), ale zpomalíte jakékoliv dohledání (což je častější operace).
O velké tabulce píšete vy. Jakékoli dohledání tím nezpomalím, právě naopak – dohledání „které záznamy mají tento štítek“ se tím mírně zrychlí, protože se půjde přes jeden index a ne přes dva. Dokonce pokud budu chtít vypsat třeba jen názvy těch záznamů, a bude to fakt častá operace, můžu je přidat do toho indexu a nemusí se pak číst ani ta tabulka.

Řazený stránkovaný výpis všech štítků by byl lehce neefektivní, ale žádná tragédie (pokud by k jednomu štítku nepříslušely tisíce záznamů).

Jinak pokud by mi někdo dal obecné zadání „štítky k entitám“, nic víc bych o tom nevěděl, tak bych samozřejmě také volil tabulku se seznamem štítků a M:N tabulky mezi entitami a štítky. Ale nemám tak málo zkušeností, abych tvrdil, že je to nejlepší řešení absolutně vždy ve všech případech. A hlavně to neobhajuju nesmysly typu „často bude potřeba uživateli vypsat nestránkovaně seznam všech štítků“. Použil bych to řešení proto, že je implementačně nejjednodušší a je tradiční. Nějaké optimalizace toho jednoduchého řešení má smysl řešit teprve tehdy, až se ukáže, že současné řešení nedostačuje. Přičemž příkladem takové optimalizace (u štítků opravdu jen teoreticky) může být právě denormalizace a uvedení štítků přímo u záznamů (což by byl problém u vícenásobných štítků, pak by bylo nutné to řešit buď polem nebo další tabulkou), která umožní snížení počtu použitých indexů. Při hledání pouze přes štítky by úspora byla minimální, ale kdybyste chtěl kombinovat hledání „dej mi všechny záznamy, které mají štítek X, patří do kategorie Y a vytvořil je uživatel Z“, může už být podstatný rozdíl, jestli databázi donutíte slévat desítky tisíc záznamů ze tří indexů, aby tam našla průnik pěti záznamů, nebo zda těch pět záznamů najde přímo v indexu. Samozřejmě to zase závisí na tom, jaké typy dotazů uživatelé používají – pokud bude kombinací podmínek 60, asi nebudete chtít mít 40 indexů, abyste pokryl všechny varianty dotazů.

Kit

  • *****
  • 704
    • Zobrazit profil
    • E-mail
Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #218 kdy: 25. 10. 2019, 20:19:53 »
My ale umíme udělat našeptávač štítků. Jen k tomu nepoužíváme indexy do obřích tabulek, protože víme, že by to bylo zoufale neefektivní a uživatel by mezitím mohl usnout.
Google má vyhledávač a má v něm i našeptávač. Buď je to zoufale neefektivní a uživatelé u toho usínají, nebo nemá zaindexováno moc dokumentů, nebo používá nějakou jinou zázračnou metodu, než indexy. A nebo neplatí váš předpoklad efektivita správného indexu pro fulltextové vyhledávání není tolik citlivá na počet zaindexovaných dokumentů/záznamů.

Pomiňme, že Google pro tento účel nepoužívá SQL, ale vlastní databázi Big Table.

Jenže i v SQL tohle umíme. Stačí jen tu databázi normalizovat. Tabulka se nám rozpadne na tři tabulky a ejhle, najednou našeptávač neprochází milióny záznamů se štítky, ale jen stovky. Navíc je tabulka se štítky velmi úzká a tedy i rychlá. Samozřejmě má i svůj index.

Logik

  • *****
  • 1 022
    • Zobrazit profil
    • E-mail
Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #219 kdy: 26. 10. 2019, 13:06:28 »
Výborně, zadání máte, Tak si teď zkuste odpovědět na otázku: Kdo bude lepší v hledání duplicit ve stovkách štítků?
Člověk, protože počítač neodhalí např. duplicitu novinka versus news. Nebo nedovede vyřešit to, že když je štítků moc různých a je třeba sjednotit (např. zahrnout auto a autobus pod jeden štítek dopravní prostředek), nebo nějak lépe strukturovat.  Samozřejmě, taková revize jde dělat jen do určitého počtu štítků. Ale to, že těch štítků bude více, to je jen Tvoje utkvělá představa, ke které ses upnul, aby si nemusel přiznat, že je toto v některých případech validní usecase. Je mnoho oblastí, kde je reálně používý počet štítků řádově desítky (ač štítkovaných třeba stovky tisíc), a tam je takové review otázkou pár minut.

V každém případě, zadání nebylo odstranit duplicitu štítků. Od začátku jsme se tady bavili o seznamu štítků a jak ho udělat. Teprv, když jste zjistil, že to neumíte, tak hledáte, jak se z toho vykecat a vymyslel jste si, že vlastně místo seznamu štítků budete dělat našeptávač.Vozit uhlí a ne lidi.

Citace
Mimochodem, když pro přiřazování štítků použijete našeptávač, těchto případů bude existovat minimum, a nejspíš je někdo opraví daleko dřív, než by se k tomu dostal nějaký správce.
Na to se dá říci jen to, že jste evidentně nikdy žádnou reálnou databázi vyplňovanou uživateli nespravoval.
Citace
Indexy na tento typ úlohy jsou dělané. Např. Lucene (NoSQL databáze pro fulltext)
Ano, v NOSQL databázích, kde člověk nemá možnost vytvářet normalizované datové struktury, to je třeba řešit a ty databáze to zpravidla umějí. V SQL databázích se to řeší normalizací a tedy tam zpravidla tato funkcionalita implementovaná není. My jsme se ovšem jaksi bavili o implementaci v SQL databázi. Vždyť jsem psal, pokud neumíte SQL, tak radši používejte NoSQL databáze. Pak ale neraďte lidem, jak implementovat strukturu v SQL databázi.
Citace
Ano, to je jedna z možných implementací. Ovšem co má společného s indexy? Vůbec nic.
No právě, pleteš sem úplně nesouvisející věci.
Citace
Takže jsem logicky psal o té další možné implementaci
Ano, pořád dokolečka si vymýšlíte, jak by něco implementováno být MOHLO, protože nevíte, jak věci implementované JSOU. Pro spellchecking je hunspell algoritmus nepsaný standard (obzvlášť v jednodušších implementacích fulltextu, o kterých jste mluvil) a tedy pokud bez dalšího mluvíte o spellchekingu, tak každý, kdo o věci něco ví, bude předpokládat, že mluvíte o tomto algoritmu.
Zadruhé si pletete spellchecking a "suggestions", česky našeptávání. Spellcheck je kontrola vůči slovníku, našeptávání je napovídání nejlepšího známého inputu k zadané frázi. Takže vlastně tady tvrdíte, že se našeptávání implementuje pomocí našeptávání. Hezká tautologie.
Citace
kterou ve skutečnosti používá každý spellchecker, minimálně pro uživatelský slovník
Zaprve, vzhledem k tomu, že je třeba nají možné korekce nejen vůči uživatelskému slovníku, ale také vůči sytémovému. Pokud je systémový implementován pomocí hunspellu, tak podobnostní hledání není možné úplně možné. Někdy se používá, pak ale je výsledek zkreslen, protože se hledá nestemované slovo vůči stemovanému indexu. Přesnější algoritmus je ovšem vygenerovaný seznam kandidátů a kontrola vůči spellchecku. Viz např. https://norvig.com/spell-correct.html
Tedy Vaše tvrzení, že spellchecker je podobnostní hledání, je prostě nesmysl - představujete si tudle problematiku jak Hurvínek válku a myslíte si, že když řeknete spellchecker, že si každý vybaví zrovna ten stejný algoritmus, který máte na mysli Vy. Ve skutečnosti myslíte jeden z X algoritmů na řešení něčeho jiného.

A za druhé, když už se používá podobnostní vyhledávání, tak ve smyslu metriky blízkosti slov, např. Levenshteinova distance (v lepších případech s přihlédnutím k možnosti fonetické záměny), a na akceleraci čehož se trigram indexy (jak v SQL databázích (pg_trgm), tak nosql fulltextech https://community.oracle.com/docs/DOC-983151), které ani náhodou nemají schopnost akcelerovat operaci distinct - takže ani tato technologie, o které tu celou dobu mylně prohlašujete, že je to základní algoritmus spellcheckeru, Vám k implementaci Vašeho vysněného indexu pro DISTINCT prostě nepomůže. Mícháte páté přes deváté.

Citace
No, pokud to programujete tak, že uživateli neposkytnete našeptávač štítků:
Todle už je hodně laciná snaha se z toho vykecat, že jo? Já na tvým místě bych se za takto chabej pokus styděl....
Nikde jsem neřekl, že štítky nebudu našeptávat, to jen takovej nesmysl se nám snažíš vložit do úst, abys nemusel uznat omyl. To, co tvrdíme, je:
a) jsou usecase i pro seznam štítků, a tvůj db model se pro tento usecase prostě nehodí, protože je pomalý a indexy neodstraní principiální problém této struktury
b) Tvůj DB model se nehodí ani pro implementaci našeptávání v SQL databázi, protože i tam narazíš na stejný problém.

Citace
Pokud mi někdo bude argumentovat tím, že našeptávání štítků v aplikaci neudělá, protože to jeho databáze neumí,
Zase lžete. Víš, proč s Tebou ještě diskutuji? Zajímá mě, jaké lži ještě dokážete vyplodit, abyste nemusel uznat omyl a Tvoje vykrucování mě baví. Sorry, že Ti to říkám tak narovinu, ale třeba Tě to přinutí se nad sebou zamyslet.

Nikdo tady netvrdil, že to db neumí, nebo že nebude dělat našeptávání. Tvrdíme, že TEBOU NAVRŽENÁ DB STRUKTURA je jak na výpis štítků, tak na našeptávání NEVHODNÁ, a že se to v databázích dělá jinak.

Citace
budu hledat jiný nástroj, který to umí..... nevím, jestli pořád ještě trváte na relační databázi....Tip pro to, jak vytvořit našeptávač se Solr 
Jééééééé. Takže místo toho, abys s minimem práce udělal rozumnou db strukturu použitelnou jak k adminu štítků, tak pro implementaci našeptávání, radši nainstaluješ další software, budeš řešit synchronizaci dat a atomicitu transakcí atd... atd... Z práce na pár hodin uděláš práci na měsíc....Je fakt zábavné pozorovat, čeho všeho jsou lidi schopní, aby nemuseli uznat omyl.

Citace
Já jsem jenom ukázal, že i ten B-Tree index pomůže i v té hloupé implementaci, kdy chcete seznam všech štítků, pokud ten seznam budete alespoň stránkovat.
Jééééé, ty jsi snad fakt doteď nepochopil, v čem je problém. Teda, čekal jsem hodně věcí, ale todle ne. Znovu: B-Tree index - přinejmenším jeho standardní implementace v běžných databázích - Ti nepomůže proti sekvenčnímu scanu všech štítkovaných (ať už v primárním datovém souboru, nebo indexu, problém je to stejný), ať už budeš stránkovat nebo ne. Zkus si několikrát znovu přečíst předchozí odpovědi týkající se tohoto, třeba Ti to konečně docvakne.

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #220 kdy: 26. 10. 2019, 15:02:02 »
Člověk, protože počítač neodhalí např. duplicitu novinka versus news. Nebo nedovede vyřešit to, že když je štítků moc různých a je třeba sjednotit (např. zahrnout auto a autobus pod jeden štítek dopravní prostředek), nebo nějak lépe strukturovat.  Samozřejmě, taková revize jde dělat jen do určitého počtu štítků.
Přesněji řečeno do počtu štítků, které je člověk schopen si najednou zapamatovat. A s takovým počtem štítků zase databáze nebude mít problém, i když bude muset tabulku načíst fullscanem (protože s tak malým množstvím štítků nebude moc ani oštítkovaných entit).

Ale to, že těch štítků bude více, to je jen Tvoje utkvělá představa, ke které ses upnul, aby si nemusel přiznat, že je toto v některých případech validní usecase.
Bavili jsme se totiž o optimalizaci výpisu. Pokud je záznamů pár, není nutné pro takovéhle specifické použití dělat nějakou optimalizaci. Holt si ten administrátor jednou za měsíc deset sekund počká – to ruční třídění štítků mu pak zabere řádově víc času.

V každém případě, zadání nebylo odstranit duplicitu štítků. Od začátku jsme se tady bavili o seznamu štítků a jak ho udělat. Teprv, když jste zjistil, že to neumíte, tak hledáte, jak se z toho vykecat a vymyslel jste si, že vlastně místo seznamu štítků budete dělat našeptávač.Vozit uhlí a ne lidi.
Ale já to umím. Já jsem jenom reagoval na váš use case, kdy už je záznamů tolik, že to bez indexu nezvládne ani databáze, natož člověk.

Ano, v NOSQL databázích, kde člověk nemá možnost vytvářet normalizované datové struktury, to je třeba řešit a ty databáze to zpravidla umějí. V SQL databázích se to řeší normalizací a tedy tam zpravidla tato funkcionalita implementovaná není.
Našeptávač štítků a normalizace databáze spolu vůbec nijak nesouvisejí.

No právě, pleteš sem úplně nesouvisející věci.
S hunspellem jste přišel vy, ne já.

Pro spellchecking je hunspell algoritmus nepsaný standard (obzvlášť v jednodušších implementacích fulltextu, o kterých jste mluvil) a tedy pokud bez dalšího mluvíte o spellchekingu, tak každý, kdo o věci něco ví, bude předpokládat, že mluvíte o tomto algoritmu.
Chvíli píšete o spellcheckeru hunspell, chvíli zaměňujete fulltext a spellchek (takže to nemůže být hunspell). Gratuluju, teď jste konečně ty dvě různé implementace nacpal do jedné věty, takže nesmyslnost vašich tvrzení o to více vynikla.

Zadruhé si pletete spellchecking a "suggestions", česky našeptávání.
Spellchecker má za úkol na základě vstupu najít možná podobná slova ze slovníku existujících slov. Našeptávač má za úkol na základě vstupu najít možné podobná slova nebo jejich části ze slovníku, nad kterým se našeptává. Spellchecker tedy může být implementován jako speciální varianta našeptávače.

A za druhé, když už se používá podobnostní vyhledávání, tak ve smyslu metriky blízkosti slov, např. Levenshteinova distance (v lepších případech s přihlédnutím k možnosti fonetické záměny), a na akceleraci čehož se trigram indexy (jak v SQL databázích (pg_trgm), tak nosql fulltextech https://community.oracle.com/docs/DOC-983151), které ani náhodou nemají schopnost akcelerovat operaci distinct - takže ani tato technologie, o které tu celou dobu mylně prohlašujete, že je to základní algoritmus spellcheckeru, Vám k implementaci Vašeho vysněného indexu pro DISTINCT prostě nepomůže. Mícháte páté přes deváté.
Výborně, takže už jste si dostudoval základy toho, o čem se chcete bavit. Teď už si to jenom správně spárujte – o fulltextech a trigram indexech byla řeč v souvislosti s našeptávačem.


a) jsou usecase i pro seznam štítků, a tvůj db model se pro tento usecase prostě nehodí, protože je pomalý a indexy neodstraní principiální problém této struktury
Zapomněl jste dodat, že jde o use case, kde je štítků i záznamů málo a příslušný use case se používá jen občas. Takže to, že je „pomalý“, nemusí vadit.

b) Tvůj DB model se nehodí ani pro implementaci našeptávání v SQL databázi, protože i tam narazíš na stejný problém.
Vždyť už jste konečně zjistil, že i v relačních databázích existují fulltextové indexy. To už jste to zase zapomněl?

Zase lžete. Víš, proč s Tebou ještě diskutuji? Zajímá mě, jaké lži ještě dokážete vyplodit, abyste nemusel uznat omyl a Tvoje vykrucování mě baví. Sorry, že Ti to říkám tak narovinu, ale třeba Tě to přinutí se nad sebou zamyslet.
Pouze jsem se přizpůsobil vašemu stylu.

Nikdo tady netvrdil, že to db neumí, nebo že nebude dělat našeptávání. Tvrdíme, že TEBOU NAVRŽENÁ DB STRUKTURA je jak na výpis štítků, tak na našeptávání NEVHODNÁ, a že se to v databázích dělá jinak.
O dvě citace výš jste psal, že při implementaci našeptávání v SQL databázi narazíte na problém. Teď zase tvrdíte, že to žádný problém není. Tak která varianta platí?

Ano, navržená struktura není vhodná pro výpis všech štítků, pokud bude entit větší množství. Jenže já jsem nikde nepsal, že je ta struktura vhodná na všechny případy použití. Ten váš příklad, kdy je potřeba vypisovat větší množství štítků najednou, přece také není vhodný pro všechny případy použití. Tak já nemohu psát o speciálních případech a vy ano?

Jééééééé. Takže místo toho, abys s minimem práce udělal rozumnou db strukturu použitelnou jak k adminu štítků, tak pro implementaci našeptávání, radši nainstaluješ další software, budeš řešit synchronizaci dat a atomicitu transakcí atd... atd... Z práce na pár hodin uděláš práci na měsíc....Je fakt zábavné pozorovat, čeho všeho jsou lidi schopní, aby nemuseli uznat omyl.
Zase lžete. Víš, proč s Tebou ještě diskutuji? Zajímá mě, jaké lži ještě dokážete vyplodit, abyste nemusel uznat omyl a Tvoje vykrucování mě baví. Sorry, že Ti to říkám tak narovinu, ale třeba Tě to přinutí se nad sebou zamyslet.

Jééééé, ty jsi snad fakt doteď nepochopil, v čem je problém. Teda, čekal jsem hodně věcí, ale todle ne. Znovu: B-Tree index - přinejmenším jeho standardní implementace v běžných databázích - Ti nepomůže proti sekvenčnímu scanu všech štítkovaných (ať už v primárním datovém souboru, nebo indexu, problém je to stejný), ať už budeš stránkovat nebo ne. Zkus si několikrát znovu přečíst předchozí odpovědi týkající se tohoto, třeba Ti to konečně docvakne.
Při řazeném stránkovaném výpisu B-Tree index pomůže, protože databáze pojede po tom indexu a bude počítat, kolik má unikátních záznamů, a až jich napočítá dost, tak skončí. Když nebude mít ten index, musí načíst všechny záznamy z tabulky, jejich hodnoty seřadit – a pak může konečně začít dělat to, co před tím dělala nad indexem. Když těch štítků bude málo, takže nepotřebujete stránkovat, bude to podobné, akorát je podle indexu vypíše všechny. To, k čemu tam ten index je, je to řazení záznamů – odpadne ta potřeba vše načíst a seřadit až v okamžiku dotazu, protože už je to uložené v tom indexu.

Už jste pochopil, v čem je problém?

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #221 kdy: 26. 10. 2019, 15:04:30 »
Pomiňme, že Google pro tento účel nepoužívá SQL, ale vlastní databázi Big Table.

Jenže i v SQL tohle umíme. Stačí jen tu databázi normalizovat. Tabulka se nám rozpadne na tři tabulky a ejhle, najednou našeptávač neprochází milióny záznamů se štítky, ale jen stovky. Navíc je tabulka se štítky velmi úzká a tedy i rychlá. Samozřejmě má i svůj index.
Jenže tady vůbec nejde o databázi, ale o index. Našeptávač opravdu nemůže dělat fullscan tabulky, ani malé. Našeptávač musí vždy pracovat nad indexem. Teda pokud budete našeptávat z deseti hodnot, nemusíte to vůbec řešit v databázi a vyřešíte to na klientovi, ale o takovém případu se snad nebavíme.

Logik

  • *****
  • 1 022
    • Zobrazit profil
    • E-mail
Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #222 kdy: 26. 10. 2019, 15:10:09 »
Citace
O velké tabulce píšete vy. Jakékoli dohledání tím nezpomalím, právě naopak – dohledání „které záznamy mají tento štítek“ se tím mírně zrychlí, protože se půjde přes jeden index a ne přes dva.
Tady se opět mýlíš. Protože dohledání bude sice přes dva indexy, ale jejichž souhrnná velikost a tedy i hloubka bude plus mínus podobná tomu jednomu indexu, velikost a rychlost dohledání samotného štítku bude oproti dohledání těch záznamů zanedbatelná úloha. Ovšem paměťová náročnost bude podstatně větší, protože ten ohromnej "denormalizaovanej index" bude jinak k ničemu, zatímco v druhém případě se použije malinký index přes štítky plus primární klíč.
Ve výsledku tedy vzhledem k hierarchickému paměťovému systému bude na rozumně zatížené databázi řešení s dvěma indexy zpravidla rychlejší, protože se nebude muset sahat pro řídčeji používaný index do pomalejších pamětí (anebo ten index naopak z těch pamětí nevytěsní jiná data, což zpomalí ostatní dotazy).

Citace
Při hledání pouze přes štítky by úspora byla minimální, ale kdybyste chtěl kombinovat hledání „dej mi všechny záznamy, které mají štítek X, patří do kategorie Y a vytvořil je uživatel Z“
Pokud je potřeba akcelerovat takovéto dotazy, pak opravdu může být denormalizace rozumná. Ovšem to už je jednak velmi speciální obor, něco, co by se rozhodně nemělo radit na webových fórech. Kdybys na začátku řekl - ano, todle je denormalizovaná struktura, která ale ve speciálních případech může mít smysl, tak by vypadala diskuse jinak. Tys to ale od začátku razil jako normální běžný přístup, a teprv teď, když vidíš, že je to neudržitelné, si najednou vytáhl denormalizaci (btw. na začátku diskuse si vůbec popíral, že Tvé řešení je denormalizace) jako úhybný manévr.

Zadruhé, běžná praxe je takováto denormalizovaná data pro účely rychlejšího přístupu držet nikoli jako primární data, ale jako "precomputed data" udržovaná triggery z původní normalizované datové struktury. Viz např.https://rubygarage.org/blog/database-denormalization-with-exampleshttp://www.ovaistariq.net/199/databases-normalization-or-denormalization-which-is-the-better-technique/takže i tak ten úhybný manévr se příliš nepovedl....

Citace
Jenže tady vůbec nejde o databázi, ale o index. Našeptávač opravdu nemůže dělat fullscan tabulky, ani malé. Našeptávač musí vždy pracovat nad indexem. Teda pokud budete našeptávat z deseti hodnot,
A kolikrát Ti budeme muset zopakovat, že INDEXY V SQL DATABÁZI PROSTĚ NEJSOU (zpravidla) NAPSANÉ TAK, ABY "ELIMINOVALI DUPLICITY", TAKŽE VE VÝSLEDKU PŮJDE I PŘI POUŽITÍ INDEXU O "SEQUENTIAL SCAN" PŘES TY DUPLICITY, než Ti to dojde? 

Kit

  • *****
  • 704
    • Zobrazit profil
    • E-mail
Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #223 kdy: 26. 10. 2019, 15:30:55 »
Když nebude mít ten index, musí načíst všechny záznamy z tabulky, jejich hodnoty seřadit – a pak může konečně začít dělat to, co před tím dělala nad indexem. Když těch štítků bude málo, takže nepotřebujete stránkovat, bude to podobné, akorát je podle indexu vypíše všechny. To, k čemu tam ten index je, je to řazení záznamů – odpadne ta potřeba vše načíst a seřadit až v okamžiku dotazu, protože už je to uložené v tom indexu.

Takhle se to skutečně nedělá. Záznamy se sekvenčně sypou do datové struktury, ve které je text štítku klíčem. Duplicita je rozpoznána ihned při vložení klíče. Žádné následné řazení ani selekce se nekoná, jen se ta struktura vyleje na výstup.

Logik

  • *****
  • 1 022
    • Zobrazit profil
    • E-mail
Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #224 kdy: 26. 10. 2019, 15:41:12 »
Citace
(protože s tak malým množstvím štítků nebude moc ani oštítkovaných entit).
To byste se divil, kolikrát je malé množství štítků a velké množství oštítkovaných entit. V případě, že se nejdená o štíky soukromé pro každého uživatele, tak je to spíše pravidlem: oni jaksi zpravidla štítky ztrácejí smysl, když jich je moc.... Tvůj předpoklad, že když je málo štítků, tak je vždy málo entit, je nesmysl, a tím padá i Tvoje argumentace.

Citace
Našeptávač štítků a normalizace databáze spolu vůbec nijak nesouvisejí.
Souvisejí, akorát to nevíš, a to tak, že fulltext nad denormalizovanými štítky bude v SQL databázi zpravidla pomalý.


Citace
S hunspellem jste přišel vy, ne já.
Slovo spellchecker jsi poprve použil v diskusi ty. A standardní implementace spellcheckru je hunspell algoritmus. Tedy toto téma jsi do diskuse zatáhl Ty - akorát, jak se ukazuje, ani nevíš, co to vlastně je.

Citace
Spellchecker má za úkol na základě vstupu najít možná podobná slova ze slovníku existujících slov.
Omyl. Spellchecker má za úkol zjistit, zdali je dané slovo součástí dané gramatiky. Ať už dané výčtem, nebo, což je daleko častější, generativní gramatikou. Umíš vůbec anglicky. Víš, co znamená to "check" v tom "spellchecker"?
Nabídka korekce není nic jiného než našeptávání, a je to jiná úloha, než spellchecker, byť s ním souvisí.

Citace
chvíli zaměňujete fulltext a spellchek
Ufff. Spellchecker a fulltext jsi právě zaměnil Ty, když jsi psal, že na to použiješ fulltext index, a když jsem se začal ptát, jak je použiješ, tak jsi začal že přeci tak, jak je to použito v každém spellcheckru.....

Citace
Vždyť už jste konečně zjistil, že i v relačních databázích existují fulltextové indexy. To už jste to zase zapomněl?
Ne, akorát Ty jsi zapomněl, že jsem Ti už několikrát napsal, že i fulltextové indexy v SQL databázích trpí stejným problémem. Tedy že vyhledání i malého počtu štítků ve velkém počtu záznamů pomocí fulltextového indexu není tak rychlé, jako vyhledání téhož v normalizované datové struktuře.
Už jsem Tě několikrát vyzýval, abys - pokud s tím nesouhlasíš, ukázal jak k takovému účelu fulltext použiješ. Vždy jsi to nějak zakecal nesmyslama o spellchekrech apod. Tak tě vyzývám znovu: pokud tvrdíš, že Ti fulltext index pomůže, ukaž praktickou implementaci.

Citace
O dvě citace výš jste psal, že při implementaci našeptávání v SQL databázi narazíte na problém. Teď zase tvrdíte, že to žádný problém není. Tak která varianta platí?
Máš evidentně problém pochopit psaný text. V Tvé databázové struktuře to problém je. V normalizované struktuře to problém není.

Citace
Při řazeném stránkovaném výpisu B-Tree index pomůže, protože databáze pojede po tom indexu a bude počítat, kolik má unikátních záznamů, a až jich napočítá dost, tak skončí.
Ano, index pomůže v řazení. Nepomůže v tom, že bude muset projít všechny záznamy indexu pro daný štítek, což může být číslo značně větší, než počet štítků. Tedy neodstraní principiální problém, že náročnost té operace nebude záviset na počtu štítků, ale počtu oštítkovaných. O tomto problému Vašeho návrhu celou dobu mluvím a psal jsem to už asi dvacet postů dozadu.