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