Zobrazit příspěvky

Nevýhody - nutnost projití dalším, mělkým a paměťově řádově méně náročným indexem, nijak nezatajuji. Jen tvrdím, že pro celkový výkon DB to není tak velká nevýhoda, jako jí zaplácnout stovky MB paměti větším indexem. Vidíš tam ještě jiné nevýhody?

Netuším, kde jste přišel na ty stovky MB a řády. Další nevýhodou je, že ten index bude efektivní jenom při hledání podle štítků – dotazy „štítek AND další podmínky“ budou mnohem méně efektivní.

Ano, přepsal jsem se. Myslím, že alespoň trochu inteligentní člověk z toho je schopen pochopit, co jsem chtěl napsat: že spellchecking není návrh správnosti, ale kontrola. Tak nevím.... nepochopil jste to? Anebo vaším cílem není diskutovat, ale něco jiného, a nepochopil jste to naschvál?

Alespoň trochu inteligentní člověk hledá jiná vysvětlení, než že jste hlupák. OK, takže už jsme si ujasnili, že na mé tvrzení, že samotný spellchecking slouží ke kontrole slov, jste reagoval tím, že to není pravda, že spellchecking přece slouží ke kontrole slov. Takže vaším cílem není diskutovat, ale hádat se? Když musíte rozporovat i to, co sám vzápětí napíšete stejně…

Ne, problém je, že každou chvíli tvrdíte něco jiného, podle toho, co se zrovna povede vyvrátit tak, že už nemáte žaludek na tom dál trvat.Např. na začátku jste tvrdil, že

"To je prostě množina slov, ve které se dá rychle vyhledat, jestli v ní dané slovo je nebo není..."
chvíli poté
"Spellchecker má za úkol na základě vstupu najít možná podobná slova ze slovníku existujících slov."
a teď zas tvrdíte, že jste to netvrdil a že spellchecker je kontrola správnosti, takže první definice.

To ovšem nevysvětluje, proč vyvracíte tu první definici, abyste ji vzápětí sám použil.

Odkaz se nějak pomrvil, správný odkaz je tady:
https://cs.wikipedia.org/wiki/Form%C3%A1ln%C3%AD_gramatika

No jo, jenže tenhle odkaz zase nijak nepotvrzuje vaše tvrzení.

A co se týče toho, kdo neví, jak spellchecker funguje, tak já nemluvil o spellcheckru jako o indexu....

Vždyť jsem to psal, že nevíte, jak spellchecker funguje.

Citace
Zjistěte si, co je to našeptávač. Našeptávač na dotaz „nov“ nabídne „novinky“.
Tak proč jste do toho celou dobu tahal cituji: "možná podobná slova ze slovníku existujících slov."? Najednou, když jste zjistil, že ani to neumíte, tak to také není potřeba? Dobrý našeptávač si poradí i s překlepy.

Už zase si pletete našeptávač a spellchecker. Citoval jste část věty, která celá zněla takhle: „Spellchecker má za úkol na základě vstupu najít možná podobná slova ze slovníku existujících slov.“

Takže pokud ten dotaz poběží nad tou strukturou, kterou tu celou dobu prosazujete, tak vám to našeptá jeden stejný výraz tisíckrát.

Ten dotaz nic nenašeptává, vrací seznam entit podle zadaného textu štítků.

Tak to se omlouvám, to, že napíšeš dotaz vracející jiný výsledek než chceme jsem nečekal

Ono je totiž těžké z vašich komentářů zjistit, co vlastně chcete – teda kromě toho, že se chcete hádat za každou cenu.

Takže Tě prosím znovu, ukaž dotaz, který umí efektivně vrátit z Tebou prosazované datové struktury unikátní našeptávací návrhy.

Kód: [Vybrat]

CREATE INDEX idx_stitky_gist ON stitky USING GIST(stitek gist_trgm_ops);

SELECT DISTINCT ON (stitek) AS nazev, stitek <<<-> query AS vzdalenost
  FROM stitky
  WHERE stitek <<% query
  ORDER  BY vzdalenost DESC, stitek
  LIMIT 10;

to co vám celou dobu tvrdíme je

Ne, tohle jste teď napsal poprvé. A ještě nejspíš píšete jen o PostgreSQL, ne obecně o relačních databázích (a už vůbec ne o databázích obecně).

TEDY JE VAŠE ŘEŠENÍ PRO PŘÍPAD SQL DATABÁZÍ ANTIPATTERN

Vidím, že vám dělá radost, že s vámi v něčem souhlasím, takže to budete pořád dokola opakovat, dokonce to musíte vyřvávat. Sice je to mimo téma diskuse, protože já jsem nikdy netvrdil, že je to doporučený postup, jak ve většině případů dělat štítky, ale když vám to dělá radost to pořád opakovat…

A nejste schopen připustit, že ač by index v databázi mohl být implementován tak, že by akcelerovat DISTINCT, že tak prostě v drtivé většině prostě NENÍ.

Opět se mýlíte. Já jsem se k DISTINCTu nevyjadřoval, protože to nebyla věc, kterou bych v téhle diskusi řešil. Když jsme si ujasnili, že vážně chcete na uživatele nasypat seznam všech štítků, potvrdil jsem vám, že pro takový případ opravdu není vhodná taková struktura databáze, jakou jsem popsal.

Úplně stejný problém je s tím spellcheckingem: myslel jste si, že je implementován jako index a samozřejmě, že by tak být implementován mohl. Ovšem prostě v majoritních spellchekrech tak implementován NENÍ. Běžné formáty slovníků pro spellchecking nedávají seznam slov výčtem, ale gramatikou.

Myslíte, že třída HashMgr je ve zdrojácích hunspellu jenom omylem a nepoužívá se? Nebo to podle vás není index?

2167

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 27. 10. 2019, 08:30:02 »

Ovšem i u M:N relace (kde jde o dva/tři indexy) je furt výhodnější normalizovaná struktura a tedy mít malý varchar index pro seznam štítků a velký integer index pro vazební tabulku. Furt to dohromady zabere méně místa v paměti, než jeden velký varchar index pro "vazební" tabulku. Průchod integer indexem je také o fous rychlejší.

Jestli je to výhodnější nezjistíte tak, že vypíšete výhody a zatajíte nevýhody.

Argumentovat nevhodností nějakého postupu tím, že nefunguje v blbě navržené db struktuře (nebo popř. v DB struktuře, která má smysl jen ve velmi raritním případě), je nesmyslná argumentace. Tedy pro to, abys obhájil svůj argument, musel bys obhájit to, že tvoje struktura není antipattern. Což nejde, protože to je antipattern, který mrví výkonnost dotazů (viz níž).

Zase si vymýšlíte. Já jsem štítky neuváděl jako argument pro vhodnost či nevhodnost nějakého postupu.

Ty jsi doteď ještě nepochopil, že jeden z velkých problémů Tvé DB struktury je to, že bude mít v indexu duplicitně uvedené štítky, takže není rychlá cesta, jak prohledávat názvy štítků? A že to je ta věc, kterou od začátku kritizujeme?

Nepochopil jsem, proč to musíte připojovat i k vláknům, která s tím nijak nesouvisí.

Psal. Psal jsi o klasickém algoritmu na spellchecking, což je prostě hunspell.

A další váš výmysl.

Citace
Omyl. „Check“ znamená kontrola – přičemž obě naše tvrzení popisují kontrolu.
Ne, návrh opravy chyby opravdu NENÍ kontrola správnosti, i kdyby ses postavil na hlavu. Navíc opět lžete a překrucujete, na počátku jste o spellchecku mluvil jako, cituji: "To je prostě množina slov, ve které se dá rychle vyhledat, jestli v ní dané slovo je nebo není.... té struktuře, která umožňuje rychlé vyhledávání, se říká – index.". Tedy na začátku jste definoval spellchecker jako něco, co kontroluje, jestli slovo patří do dané množiny.

V první větě rozporujete, že spellchecker není kontrola správnosti, abyste ve zbytku odstavce dokazoval, že to je kontrola správnosti. Spíš si to nejdřív ujasněte sám, a pak se teprve pouštějte do diskuse.

Teprve když jsem vyvrátil Váš omyl, že ovšem standardní implementace spellcheckeru není implementována indexem, nýbrž generativní gramatikou, takže se to našeho problému vůbec netýká, tak jste začal jste překrucovat svoje slova i realitu, že podle Vás najednou není spellchecker něco, co kontroluje, jestli dané slovo patří do dané množiny či ne, ale nápověda v případě chyby. Což je úplně jiný problém.

Problém je totiž v tom, že neustále vyvracíte věci, které jsem nenapsal.

Prosím, zjisti si, co znamená v programování gramatika, zas neznáš základní termíny a pleteš si pojmy s dojmy.
https://cs.wikipedia.org/wiki/Form%C3%A1ln%C3%AD_gramatikaSpellchecking, tedy kontrola hláskování, se v programování kontroluje gramatikami.

Další nesmysl. A to vám není hloupé odkazovat na neexistující stránku? To jste si myslel, že si toho nevšimnu? Navíc nemůžu za to, že znáte jenom jedinou metodu implementace spellcheckeru, u které navíc ani nevíte, jak funguje.

To sice zpravidla je, ale jde o přibalení jiného algoritmu řešícího jinou věc, než samotný spellchecking.

Ano, ale je dobré na to myslet už při návrhu algoritmu samotného spellcheckeru. Jinak byste také mohl navrhnout hash index, ve kterém budete zjišťovat existenci slov, a pak zjistíte, že pro návrh možných korekcí vám je ten index úplně k ničemu.

1) toto je vyhledávání štítku se stejným kořenem, respektive u víceslovných štítků, kde se shodují alespoň nějaké kořeny. Nijak to tedy neřeší původní problém: výpis všech štítků.

O tom vašem „původním problému“ už jsme si vysvětlili, že je to velmi raritní případ, tudíž je to nesmyslná argumentace.

2) Neřeší to ani našeptávání štítků, protože na dotaz: "novikny" to nenajde "novinky". Není to ani podobnostní hledání, o kterém tu celou dobu mluvíš.

Zjistěte si, co je to našeptávač. Našeptávač na dotaz „nov“ nabídne „novinky“.

3) Užití GIN indexu tady vůbec nedává moc smysl: To je právě jeden z Tvých omylů, že se našeptávače implementují pomocí fulltextových indexů. Ano, někdy implementují, ovšem nikoli vždy, pouze pokud je k dané entitě přiřazený delší text. Pokud je k dané entitě přiřazený pouze jednoslovný text - jako např. zpravidla u štítků - je použití GIN indexu nesmysl. Daleko lepší výsledky dá vyhledávání pomocí trigram indexů. Toto už píšu asi po páté.

Běžně se používají i víceslovné štítky. Navíc jste chtěl řešení ve standardním Postgresu, předpokládal jsem tedy PostgreSQL bez extenzí. Tak se předveďte, jak v PostgreSQL bez extenzí vytvoříte trigram index.

4) A PŘEDEVŠÍM TVŮJ PŘÍKLAD JEN DOKAZUJE, ŽE MÁME CELOU DOBU PRAVDU, PROTOŽE I V TVÉM DOTAZU SE NAČTOU VŠECHNY HODNOTY A PAK SE NA NICH PROVEDE UNIQUE. I toto Ti píšu asi po páté.

Kde v mém dotazu se provádí unique?

=> explain select distinct test from translations where test @@ '''teaser_cards_temp''';

Ano, tenhle dotaz je trochu podobný mému dotazu. Jsou tam stejná slova SELECT, FROM a WHERE. Ale to jsou klíčová slova jazyka SQL, vyskytují se prakticky ve všech dotazech.

Já jsem Ti demonstroval na jednom konrkétním indexu, že Tvoje představa nefunguje.

Kdybyste věděl něco o databázích, věděl byste, že to, že na něco nejde použít jeden typ indexu, neznamená, že jiný typ indexu selže také. Proto máme různé typy indexů, protože se každý hodí na něco jiného.

Nemůžu za to, že nemáš evidentně praxi s databází, ale si chytrej jak rádio, takže místo toho, aby ses chytil za nos a nechal se poučit, tak nám nevěříš, že se to týká i jiných typů indexů, a dál meleš nesmysly.

Obecně jiných typů indexů se to netýká, sám jste už vyjmenoval typy indexů, které to zvládnou v pohodě, jsou dokonce s tím záměrem vytvořené.

Věřit vám, že se to týká i jiných typů indexů, nebude nikdo soudný – velký kvantifikátor („pro všechna X platí“) nemůžete dokazovat příkladem (malým kvantifikátorem – „existuje X, pro které platí“).

Ten příklad, který jste uvedl, totiž závisí na mnoha faktorech, které jste neuvedl. Jedním je konkrétní implementace B-Tree – i B-Tree index je možné implementovat tak, že v něm každý klíč bude jenom jednou, a duplicity budou řešené seznamem odkazů na záznamy. Dál to závisí na tom, zda plánovač dotazů dokáže nebo nedokáže DISTINCT stlačit (push down) do podmínek.

Citace: Kit 26. 10. 2019, 15:47:39

To, že pomůže při řazení ale nikdo nerozporoval ani nerozporuje. Celou dobu Ti tvrdíme, že neodstraní nutnosti nějaké formy sequential scanu přes všechny duplicitní záznamy, což je podstata problému, a to prostě neodstraní. Tak fakt nechápu, proč to sem furt taháš. To, že se dají kladivem dobře zatloukat hřebíky, nijak nemění, že používat ho na krájení chleba je pitomost, byť s ním třeba ten chleba ukrojíš líp, než řemdihem.

Já nerozporuju, že při použití pro raritní případ výpisu všech štítků bude muset PostgreSQL při použití B-Tree indexu projít přes všechny duplicitní záznamy. To jenom vy máte potřebu to pořád psát u nesouvisejících komentářů.

2168

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 26. 10. 2019, 16:30:10 »

Fullscan tabulky do tisíce záznamů je rychlejší, než použití indexu. Index pro více záznamů má význam až při selekci, tedy výběru podmnožiny, např. klauzulí WHERE, která vybere méně než cca 10-50 % záznamů.

Pro našeptávač pak ale ještě potřebujete hledat v textech těch jednotlivých záznamů. Takže tím fullscanem tabulky by to neskončilo.

2169

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 26. 10. 2019, 16:25:50 »

Citace: Logik 26. 10. 2019, 15:10:09

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).

To ale popisujete případ 1 entita = 1 štítek. Když použijete vazební tabulku mezi tabulkou entit a tabulkou štítků, abyste u jedné entity mohl mít více štítků, bude index nad touhle tabulkou ještě méně používaný, než index nad seznamem štítků. Na počet odkazovaných záznamů ale ten index bude stejně velký, jako ten „ohromný denormalizovaný index“.

Citace: Logik 26. 10. 2019, 15:10:09

Tys to ale od začátku razil jako normální běžný přístup

Ne, já jsem to na začátku uvedl jako příklad. „Takhle také někdy může vypadat struktura databáze, jak tam budete aplikovat vaše pravidla.“ A vůbec tam nešlo o žádné vyhledávání ani výpis všech štítků. Nemůžu za to, že jsou tu lidé, kteří neumí uznat chybu, tak se radši chytí něčeho nesouvisejícího a začnou se točit na tom.

Citace: Logik 26. 10. 2019, 15:10:09

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?

On vás někdo nutí, abyste to psal k naprosto nesouvisejícím komentářům? Bylo snad v mém textu, nebo v komentáři Kita, na který jsem reagoval, něco o duplicitách?

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.

Nikoli, já jsem o hunspellu nic nepsal. Psal jsem o spellcheckeru v souvislosti s našeptávačem a fulltextem.

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í.

Omyl. „Check“ znamená kontrola – přičemž obě naše tvrzení popisují kontrolu. Problém bude v té druhé části, v tom „spell“. Jde o to, jestli to slovíčko znamená spíš „gramatika“ nebo spíš „hláskování“. Nabídka korekce je standardní součástí funkce spellcheckeru, bez ní by byl velmi uživatelsky nepřívětivý.

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.

PostgreSQL:

Kód: [Vybrat]

CREATE INDEX idx_stitky ON stitky USING GIN (to_tsvector('english', stitek);
SELECT *, ts_rank_cd(to_tsvector('english', stitek), query) AS rank
  FROM stitky, plainto_tsquery(…) query
  WHERE to_tsvector('english', stitek) @@ query
  ORDER BY rank DESC
  LIMIT 10;

Citace: Kit 25. 10. 2019, 20:19:53

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.

Ano, zvolil jste pro tuhle úlohu špatný index – B-Tree vám nepomůže tolik v odstranění duplicit. Ale není pravda, že nepomůže vůbec, pomůže alespoň v tom řazení.

2170

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« 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.

2171

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« 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.

Citace: Kit 25. 10. 2019, 15:09:21

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?

2172

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« 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ů.

Citace: Miroslav Šilhavý 25. 10. 2019, 16:53:44

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í.

Citace: Miroslav Šilhavý 25. 10. 2019, 16:53:44

Š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ů.

2173

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 25. 10. 2019, 14:55:27 »

Citace: Kit 25. 10. 2019, 09:13:40

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ů.