Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Logik

Stran: 1 ... 15 16 [17] 18 19 ... 68
241
/dev/null / Re:Těžké OOP problémy
« kdy: 12. 11. 2019, 22:20:02 »
Teda, ne že bych byl kreacionista, ale zrovna todle by problém nebyl, i kdybych byl:
Citace
Priklad: Kde vzal Kain zenu?.....Je pak zajimave pozorovat, ze se musi postupne srovnat s tim, ze podle vlastni viry jsou potomci bratrovraha...
Viz Gen 5:4
Citace
Po zplození Šéta žil Adam ještě osm set let a zplodil syny a dcery.
Co si to nejdřív aspoň jednou přečíst? :-)

Citace
Kdo není proti nám, je s námi. (Marek 9:40)
Kdo není se mnou, je proti mně (Lukáš 11:23)

Tak jak to teda je?
Tam je úplně jiný kontext, ty výroky jsou ve skutečnosti ortogonální.

242
Hardware / Re:Jaké LED žárovky domů?
« kdy: 10. 11. 2019, 14:39:24 »
Na stěnu rozumně drží klasickej chemopren.

243
Hardware / Re:Redukcia serial 25M/25F
« kdy: 07. 11. 2019, 23:13:06 »

244
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 27. 10. 2019, 19:27:46 »
Jinými slovy, "když jsem zkusil asi pěti pokusy napsat efektivní dotaz a nikdy se mi to nepovedlo, a když jsem konečně zjistil, že to opravdu nejde, tak se z toho musím nějak vykecat."
Tak jo, beru to, čekal jsem, že líp uznat omyl nebudeš umět.

PS: Pro příště: méně trapné je radši neodpovědět vůbec, když už jsi příliš hrdý na to se omluvit.
 

245
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 27. 10. 2019, 17:13:05 »
Citace
Netuším, kde jste přišel na ty stovky MB
Netušíte, protože evidentně nemáte s DB zkušenost. Vemte si velkou tabulku, udělejte jí index nad varchar a integer sloupcem a koukněte se, jak je veliký... A to obzvlášť, když budete mít víceslovné, tedy dlouhé štítky.

Citace
a řády.
Pokud bude počet štítků řádově menší než počet oštítkovaný, tak bude kupodivu řádově menší index nad těmi štítky než nad vazební tabulkou. To musím vysvětlovat i takovéto primitivnosti?
Citace
dotazy „štítek AND další podmínky“ budou mnohem méně efektivní.
Udržíš moč? Protože myšlenku evidentně ne. :-) Teď se - na Tvůj popud - bavíme o situaci M:N, kde žádná taková výhoda denormalizace není.

Citace
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.“
Z té TVÉ věty je evidentní, že spellchecker s našeptávačem si pleteš dohromady TY. Už jsme se tedy doufám shodli, že návrh/našeptání korekce a spellchecker jsou dvě různé věci. Já se akorát ptal, proč návrh korekce (ať už jí nazýváš dobře nebo špatně), jsi do toho vůbec pletl, když teď tvrdíš, že taková funkcionalita vůbec není potřeba.

Citace
Ten dotaz nic nenašeptává, vrací seznam entit podle zadaného textu štítků.
A proč ho sem dáváš? Když celou dobu řešíme to, že Tvá databázová struktura není efektivní pro našeptávání štítků, a o vyhledávání entit se tu nikdo v této souvislosti nebavil? A když to byla tvá odpověď na: "....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...", tedy na dotaz jak uděláš efektivní vyhledávání štítků a ne štítkovaných entit???,
 
Citace
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;
Ufff. Zaprve, tendle dotaz je úplně špatně. Neumíte vůbec pracovat s DISTINCT ON. Pominu-li, že nevíte, že DISTINCT ON neříká, které sloupce mají být ve výstupu, takže DISTINC ON AS je nesmysl, tak máte blbě i ORDER BY, protože DISTINCT ON vyžaduje správný ORDER. Takovýto dotaz se musí napsat se subselectem (který vám mimojiné odhalí marnost vašeho počínání :-)). No a pak tam máte i blbé operátory, ale to jste asi jen blbě opsal manuál....

A zadruhé, když ty všechny chyby opravíte tak, že to bude fungovat, tak to opět bude stejná písnička, bude se tam provádět UNIQUE operace nad stejnými záznamy. Jen jste opět  prokázal, že to prostě napsat neumíte (protože to ani nejde). Ale aspoň jste si konečně zjistil něco o trigram indexes.


Citace
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ě).
To je holt problém, když místo toho, co bys pořádně četl, co Ti tu lidé píší, tak jen dokolečka tvrdohlavě opakuješ svůj názor, dávno v diskusi vyvrácený.
Psal jsem Ti to např. tady:https://forum.root.cz/index.php?topic=21909.msg319312#msg319312a tady
https://forum.root.cz/index.php?topic=21909.msg319198#msg319198a psali Ti to i jiníhttps://forum.root.cz/index.php?topic=21909.msg319193#msg319193další výskyty mě už nebaví hledat.

A píšeme tam o jiných databázích, protože toto je zrovna věc, která funguje plus mínus všude stejně, nejoptimálnější implementace indexů prostě distinct akcelerovat neumí, a protože to v rozumných DB strukturách potřeba není, tak se zpravidla pro tento účel speciální indexy nezavádí.

Už chápete, proč radši některé věci zdůrazňuji "křikem", když je píšu poxté a doteď jste to ignoroval? Teď Vás to donutilo aspoň to vnímat.

Citace
Opět se mýlíte. Já jsem se k DISTINCTu nevyjadřoval,
Takže se tady celou dobu nebavíme o našeptávání štítků? ??? Které jaksi v té Tvé struktuře bez distinctu napsat prostě nejde? ??? ? Nebo tvrdíš, že to nějak napíšeš bez distinctu? A todle psal kdo? Mimozemšťan?
Citace
SELECT DISTINCT v takovém případě bude full table scan
O existenci indexů jste už slyšel?
Od toho debata začala a celou dobu po Vás chci, abyste ukázal, jak toto naimplementujete, a to buďto pro výpis štítků (kde jste se nejprve snažil a pak prohlásil, že to není potřeba), nebo alespoň pro našeptávání (kde jste si zatím netroufl tvrdit, že to není potřeba).Protože tvrdím, že to efektivně našeptat nejde a tedy že je vaše datová struktura nevhodná.

Citace
To ovšem nevysvětluje, proč vyvracíte tu první definici, abyste ji vzápětí sám použil....
Máš evidentně problém s pochopením psaného textu. Nevyvracel jsem, že spellchecker slouží k testování toho, že dané slovo patří do množiny. Vyvracím Ti, že je to index.

Citace
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?
Auto má motor a používá ho a motor je v autě podstatný. Znamená to, že je auto motor? ??? ??? Spellcheker používá index, znamená to, že spellchecker je index? ??? Index je struktura, která slouží k dohledání záznamu v datovém souboru. Jelikož ovšem hunspell nemá žádný datový soubor, ale pouze pravidla pro generování validních slov, tak prostě není indexem.

Index se v hunspellu používá pouze k dohledání kořenů slov, nikoli k samotnému otestování, zdali je slovo validní, a je to technologicky nejméně zajímavá součást hunspellu. Takže přirovnání k autu a motoru tu vlastně nesedí, ten hashindex je v hunspellu asi v takové pozici, jako kola pro auto. Jo, auto bez kol nepojede: ale to, že umíte udělat kolo, ještě neznamená, že umíte udělat auto. A označovat kolo za auto je prostě nesmysl.

Btw. Teď jste si hezky sám vyvrátil své předchozí tvrzení, že spellcheckry přeci myslí na korekce: sám jste si dokázal, že hunspell během svého fungování používá hash a tedy nemá interní struktury optimalizované na korekce. Zkuste příště než zas plácnete nějaké "musí to tak být" tomu věnovat aspoň takovouto chvíli, jako teď, a bude diskuse o dost jednodušší. A kdybyste si ty zdrojáky hunspellu prohlédl trochu pozorněji, tak byste si ušetřil i tento omyl....

246
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 27. 10. 2019, 11:18:44 »
Citace
Jestli je to výhodnější nezjistíte tak, že vypíšete výhody a zatajíte nevýhody.
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?

Citace
Já jsem štítky neuváděl jako argument pro vhodnost či nevhodnost nějakého postupu.
Jo, takže jsme se bavili o vhodnosti DB struktury, ty jsi přišel se štítkama, ale nebyla to ukázka toho, kdy je podle Tebe nějaká struktura vhodná. Aha.....
Citace
V první větě rozporujete, že spellchecker není kontrola správnosti,
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?

Citace
Problém je totiž v tom, že neustále vyvracíte věci, které jsem nenapsal.
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.

Citace
Další nesmysl. A to vám není hloupé odkazovat na neexistující stránku? To jste si myslel, že si toho nevšimnu?
Podle sebe soudím Tebe? Víš, normální člověk nediskutuje proto, aby z druhého dělal vola, a takovéto metody nepoužívá.Zkus to prosím také, diskuse začne být o mnoho kvalitnější. Odkaz se nějak pomrvil, správný odkaz je tady:
https://cs.wikipedia.org/wiki/Form%C3%A1ln%C3%AD_gramatika

Citace
Navíc nemůžu za to, že znáte jenom jedinou metodu implementace spellcheckeru, u které navíc ani nevíte, jak funguje.
Ne, znám standardní implementaci spellcheckru, která je použita v největších SW balících (libreoffice, mozilla, chrome). A vím, že alternativní spellcheckery (ispell, aspell, myspell, snowball) používají stejný princip. Takže prostě pokud mluvíte o spellcheckru a myslíte tím jiný přístup než generativní gramatiku, tak evidentně mluvíte o něčem, co vůbec neznáte.

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

Citace
Ano, ale je dobré na to myslet už při návrhu algoritmu samotného spellcheckeru.
Ano, je dobré myslet při návrhu auta na světla. Ale když někdo mluví o tom, na jakém principu jezdí auto, tak nemyslí světlo.

Citace
Jinak byste také mohl navrhnout hash index, ve kterém budete zjišťovat existenci slov,
No, a budete asi překvapen, ale zrovna majoritní implementace: hunspell - alespoň prokazatelně v OS software - na to prostě moc nemyslela a datovou strukturu na to připravenou prostě nemá. A vzhledem k tomu, že je to majoritní spellchecker, tak pochybuji, že jsou na tom ostatní o tolik lépe, některé určitě ne, možná o trochu líp Aspell se svojí implementací soundslikes, ale on to je z principu u hodně ohýbaných jazyků těžko řešitelný problém.

Citace
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.
Zaprve to sis vysvětlil možná tak sám sobě. Zadruhé jsi původně tvrdil, že to umíš a vysmíval ses ostatním, že to neumí.
Dobře, beru toto jako přiznání, že to neumíš. Že by ses omluvil od Tebe čekat asi nemohu.

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.

Citace
Běžně se používají i víceslovné štítky.
Zaprve o tom běžně bych pochyboval (ale to těžko dokážeme), zadruhé pokud už se používají, tak jejich text má význam jako celek, čili i tam nemá fulltext (který indexuje jednotlivá slova) zpravidla smysl.
Citace
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.
pg_trgm je součástí distribuce postgresu, ač implementována jako modul. To je jako byste tvrdil, že do unixového jádra nepatří moduly a že se má člověk obejít bez nich.
Citace
Kde v mém dotazu se provádí unique?
Aha, vy to unique vlastně ani neprovádíte. 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. Tak to se omlouvám, to, že napíšeš dotaz vracející jiný výsledek než chceme jsem nečekal a myslel jsem, že máš na mysli dotaz s distinctem.
Že na to ještě ovšem upozorníš, jako by to byla přednost Tvého dotazu, nějak nechápu. 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. A klidně pomocí GIN indexu, pomineme, že dobrý spellchecker nabízí i korekce.
Jen Tě upozorňuji, abychom si ušetřili další kola Tvých marných pokusů, že Tvoje víra v schopnosti GIN indexu je mylná, protože kupodivu GIN neindexuje text jako celek, ale jednotlivá slova, takže to ani z principu nemůže umět. Fulltext index by mohl (kdyby byla taková funkcionalita zpřístupněna) efektivně vypsat unikátní použitá slova ve štítcích, nikoli unikátní štítky.

Citace
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é.

Právě jste překonal další metu: ve svém postu jsem Vám demonstroval, že to GIN index neumí, a vy na to bez jakéhokoli důkazu napíště, že to umí. Anebo jste myslel jiný index? Který konkrétně?

Citace
Ten příklad, který jste uvedl, totiž závisí na mnoha faktorech, které jste neuvedl. Jedním je konkrétní implementace B-Tree.....
Ano, a to co vám celou dobu tvrdíme je, že v databázích JSOU ty KONKRÉTNÍ IMPLEMENTACE TAKOVÉ, ŽE TO zpravidla PROSTĚ NEUMÍ, A TEDY JE VAŠE ŘEŠENÍ PRO PŘÍPAD SQL DATABÁZÍ ANTIPATTERN. Že možná vyškrábnete databázi X s indexem Y, která to jako výjimka umět bude, na té antipatternovosti nic nemění.

Celý problém naší debaty je v tom, že neznáte, jak věci implementované JSOU. A jen teoreticky přemýšlíte, jak by věci implementované být MOHLY. A když Vám ukazujeme, že se mýlíte, tak to neumíte přiznat. 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Í.
Ú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.

247
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 26. 10. 2019, 22:17:50 »
Citace
To ale popisujete případ 1 entita = 1 štítek. Když použijete vazební tabulku...
Ty jsi mluvil o jednom či dvou indexech, což odpovídá tomuto modelu jeden štítek jedna entita. 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ší.
Citace
Ne, já jsem to na začátku uvedl jako příklad. „Takhle také někdy může vypadat struktura databáze, a  jak tam budete aplikovat vaše pravidla.“
No právě. A my jste se Ti snažili vysvětlit, že takhle dobře navržená databáze nevypadná a proč.

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

Citace
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?
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?

Citace
Nikoli, já jsem o hunspellu nic nepsal.
Psal. Psal jsi o klasickém algoritmu na spellchecking, což je prostě hunspell. To, že sis pod spelcheckingem představoval jiný algoritmus, než jak je v majoritě případů implementován, není moje chyba....

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.

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.

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

Citace
Nabídka korekce je standardní součástí funkce spellcheckeru....
To sice zpravidla je, ale jde o přibalení jiného algoritmu řešícího jinou věc, než samotný spellchecking. Auto se dnes také nedělá bez světel a bylo by bez nich uživatelsky nepřívětivé, ale mluvit o výkonu auta a myslet tím jak daleko dosvítí je nesmysl. Stejnětak mluvit o algoritmu spellcheckingu a myslet návrh korekce je prostě blbina.
Citace
PostgreSQL:
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ů.
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íš.
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é.

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

Kód: [Vybrat]
Indexes:
...
    "test2" gin (test)

=> explain select distinct test from translations where test @@ '''teaser_cards_temp''';
                                         QUERY PLAN                                         
---------------------------------------------------------------------------------------------
 Unique  (cost=113233.38..114264.78 rows=206281 width=27)
   ->  Sort  (cost=113233.38..113749.08 rows=206281 width=27)
         Sort Key: test
         ->  Bitmap Heap Scan on translations  (cost=1910.68..90086.19 rows=206281 width=27)
               Recheck Cond: (test @@ '''teaser_cards_temp'''::tsquery)
               ->  Bitmap Index Scan on test2  (cost=0.00..1859.11 rows=206281 width=0)
                     Index Cond: (test @@ '''teaser_cards_temp'''::tsquery)


Citace
Ano, zvolil jste pro tuhle úlohu špatný index – B-Tree vám nepomůže tolik v odstranění duplicit.
Já jsem nezvolil špatný index. Protože dobrý index (přinejmenším v mnoha běžných DB) Tvojí strukturu prostě neexistuje. Já jsem Ti demonstroval na jednom konrkétním indexu, že Tvoje představa nefunguje. 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.

Citace
Ale není pravda, že nepomůže vůbec, pomůže alespoň v tom řazení.
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.

248
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« 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.

249
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« 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? 

250
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« 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.

251
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« 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).

252
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 23. 10. 2019, 23:42:15 »
Citace
Viděl jste někdy spellchecker, úplně tu nejprimitivnější implementaci?
Viděl. Dokonce evidentně narozdíl od Tebe jsem custom-made fulltext i implementoval, takže vím, že
a) fulltext index se spelcheckerem vlastně nijak nesouvisí, jsou to dvě úplně jiné technologie. To, že některé DB mají ve fultextových indexech zabudovaný jako preprocessing možnost stemmingu, aby ho aplikovali na data před tím, než data uloží do fulltext indexu, to nic nemění - do fulltextových indexů jdou ukládat (a i se ukládají) i nenastemmovaná data a naopak jde stemovat i něco, co neuložím do indexu.

b) spellchecker/stemmer samotný používá zpravidla hunspell algoritmus, kde sice má databázi slov, ale ve velmi speciálním tvaru (pomocí seznamu kořenů, prefixů a infixů) a jde o zcela jiné uložení dat, než je jak v B-Tree, tak ve fulltextových indexech - a s otázkou, jak něco ukládat a vyhledávat v relační databázi vůbec nesouvisí.

c) pro našeptávač je v tomto případě asi nejlepší varianta použít tzn. trigram indexy, které narozdíl od stemmingu ve fulltext indexech umí vyhledat i překlepy, to ovšem je úplně jiný typ indexu, než fulltextový index - a stejně jako fulltextový index nejde použít k akceleraci operace distinct.
d) stemming může pro jedno slovo vrátit více kořenů, takže zmiňovat ho v souvislosti s akcelerací DISTINCT operace je nesmysl.

V každém případě vyhledávání štítků pro účely našeptávání je zcela jiná úloha, než o které jsme se bavili. Kdo se tady furt vztekal, že nedodržujeme zadání? :-). My jsme se bavili o tom, jak udělat admin štítků, kde kupodivu seznam štítků potřebuji vidět i celý, např. pro to, aby ho mohl člověk jednou za čas zrevidovat a např. sloučit duplicity. Ono v reálu - pokud na to ten nástroj je - tak jde udržovat seznam štítků rozumně dlouhý a tedy revidovatelný. U této úlohy začala debata o indexu a na začátku to byl pro Vás snadný úkol, kde jste se mne snažil poučovat o indexech. Teď jsme se najednou dobrali do situace, kdy se zjistilo, že to opravdu neumíte rozumným způsobem udělat a tak to najednou není potřeba....

253
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 23. 10. 2019, 22:53:45 »
Když to je těžký, když někdo chce znova vymejšlet kolo a ještě ho vymyslí hranatý.... :-)

254
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 23. 10. 2019, 22:26:08 »
Citace
Pokud byste tedy opravdu použil pro štítky B-Tree index, máte pravdu.
Já narozdíl od Tebe netvrdím, že existuje nějaký index, který by Ti v tomto případě pomohl. Tedy jsem Ti na tom nejpřirozenějším indexu ukázal, že je to nesmysl. Ty jsi tvrdil, že Ti index pomůže a použil jsi B-Tree také. Ale furt je myšlenka, že B-Tree bude v běžných DB akcelerovat DISTINCT menší omyl (jen evidentní nedostatek praxe), než snaha použít na tento účel fulltext (což je úplné nepochopení, k čemu tento typ indexů slouží).

Citace
Nicméně pro rozumnou implementaci štítků je potřeba použít fulltextový index.
A jakej index např. v Postgres tedy použiješ? GIN nebo GIST? Nebo jiný? A to budeš hodnoty ukládat jako typ TSQuery, nebo jako jaký typ? No potěš koště....A jak Ti prosímtě takovej index pomůže????? Dáš nám sem nějaký usecase?

Jen si ve snaze nemuset uznat omyl jsi jen vymyslel ještě větší koninu. Fulltext slouží k indexaci slov v textu, nikoli k indexaci "celých hodnot" ve sloupci.Ještě tak by byl usecase pro fulltext narvat všechny štítky do jednoho pole a nad ním udělat fulltext - tam by dával tento typ indexu smysl. Ale to by jednak byla jiná struktura, než kterou si doteď razil, jednak by to byl jednak naprosto ukázkový příklad nesmyslné denormalizace, jednak ani tak by db neuměla Ti vrátit seznam použitých štítků.

Citace
...a není optimalizovaná na nesmyslné dotazy typu „potřebuji všechny štítky z databáze v náhodném pořadí“.
To byla demonstrace, že v Tvojí  struktuře to ta databáze prostě efektivně dělat nebude. Jestli Ti to nedošlo, tak kdyby to db uměla efektivně vrátit seřazené, tak by to uměla vrátit efektivně i bez požadavku na řazení - nikde není zakázáno, aby to vrátila seřazené, i když ji o to nikdo neprosí.

Citace
....že je připravená na reálné použití....
Tak už se shodneme, že Tebou navržená struktura neumí ani tak základní věc, jako vylistovat použité štítky v čase O(N), kde N je počet unikátních štítků, nebo tedy máš ještě nějaký pokus, jak znásilnit relační databázi?


255
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 23. 10. 2019, 18:52:26 »
Koukám, že jsi furt nepochopil, kde je v Tvé DB struktuře problém. Příklad byl ZÁMĚRNĚ bez řazení, aby Ti demonstroval, že INDEX NEUMÍ AKCELEROVAT OPERACI DISTINCT. V Tvém dotazu se index použije pouze na řazení, ale práci oproti full table scanu (nebo přesněji sekvenčnímu scanu, protože po nalezení dostatečného počtu hodnot se zastaví) Ti neušetří ani náhodou.

Problém je v tom, že v indexu jsou odkazy na VŠECHNY záznamy. NENÍ to seznam unikátních hodnot. Tedy když máš v tabulce milion záznamů, tak tam máš milion odkazů do primárního souboru. A pokud ten milion záznamů bude mít sto štítků s +- rovnoměrným rozdělením, tak Tvůj dotaz sice použije index, aby si ušetřil řazení, ale pořád ten Tvůj dotaz bude pro DB znamenat projít prvních sto tisíc záznamů indexu, aby těch deset unikátních hodnot našel. Skvělé, že?

Zkus si navýšit počet záznamů, aniž bys navýšil počet různých štítků - čas na dotaz Ti naroste. Btw. to je vidět i na Tvém vygenerovaném plánu, proč je tam asi ten operátor unique, že?
PS: A ano, mimochodem, přesně jsi to vystihl s tím NoSQL: ano přesně toto je důvodem boomu NoSQL databází. Protože když SQL databázi používají lidé, co jí nerozumí a dělají takovéto zprasené DB struktury, tak přechodem na NoSQL databázi jen získají. A typické je, že si myslí, že je to vina těch SQL databází....

Stran: 1 ... 15 16 [17] 18 19 ... 68