Možná řešení:
- Použití vlastní collation – můžeš vytvořit vlastní porovnávací funkci v C pomocí sqlite3_create_collation, která normalizuje text (např. odstraní diakritiku).
- Normalizace textu v aplikaci – před uložením do databáze (např. převod na ASCII v C#, Pythonu, PHP…).
- Použití externí knihovny – některé SQLite rozšíření (např. ICU) podporují pokročilejší collation.
- Přejít na jinou databázi (PostgreSQL, MySql, MariaDb, ...), která to umí
Možná se pletu, kdyžtak mě opravte, ale collation se nepoužívá na operátory like nebo glob, ne? Jen na rovnost, nerovnost.
Takže by to nefungovalo třeba na "napovídání", kdy tam třeba uživatel může napsat jen část toho řetězce a rovnout to filtruje. Třeba to tazatel nechce, nevím.
Druhá varianta mi přijde nejschůdnější a bude s největší pravděpodobností i nejrychlejší.
Už jsem to někde takhle dělal, dokonce do samostatné tabulky, kde bylo ID a názvy bez diakritiky, co s tou původní pak byla jen provázaná.
Netuším, co tazatel používá za jazyk/prostředí, ale pokud by se chtěl z jakéhokoliv důvodu vyhnout duplikaci dat, tak už mi přijde možná lepší custom skalární funkce, která prostě vstupní řetězec zbaví diakritiky (mě na se tohle osvědčilo přes nějakou unicode knihovnu převést řetězec do NFKD denormalizovaného tvaru, což rozdělí všechny znaky s diakritikou na základní písmeno a akcent, a pak se zbavit všech znaků s kódem >127.)
U custom collation se posílají dvě hodnoty a vrací se výsledek, tady by ten overhead mohl být podobný (i když záleží jestli by to dělal třeba v Pythonu nebo C) a kolik má dat, akorát by to mohlo fungovat vcelku univerzálně s jakýmkoliv operátorem.
...
BTW: Chtel bych videt, jak ten vyraz budes konstruovat, protoze to co dostanes bude "ěšžžůéíť" ... takze budes muset mit nekde definovanou jeste taky nejakou prekladovou tabulku.
Tak taky by se to dal ten regex udělat. Vezme se vstupní řetězec, zbaví se diakritiky (viz to NFKD výše). Pak se po znacích porovná vstupní řetězec s tím bez akcentů a zkonstruuje se případně ten regex výraz.
Jak to bude rychlé/pomalé, je samozřejmě otázka testu. I ty varianty s custom collation nebo skalární funkcí budou mít svůj overhead.
Jak jsem zmiňoval a bylo to i v předchozích postech, já bych se klonil k druhému uložení sloupce bez diakrtitiky, pokud by to mělo být co nejefektivnější.
Poslední příspěvky