Vlákno názorů k článku Úvaha ohledně zneužívání LIKE v databázích od Marek Chlup - Rád bych se dozvěděl, jak by měl vypadat...

Rád bych se dozvěděl, jak by měl vypadat například dotaz, který má vrátit z tabulky obsahující jména lidí všechny lidi u kterých příjmení začíná na 'ch'. Já jsem dosud žil v domnění, že "like 'ch%'" je dobré řešení.

Je to tedy špatné řešení? A jaké je správné?

Problematičnosti LIKE %neco% rozumím a jsem tedy rád, že LIKE je někdy dobře:-)

Jak však řešit případ, když si matně vzpomínám, že hledám nějakého člověka Sněhule či Uhule či Stěhule - jo jo tuším, že ve jménu se mu vyskytuje "hule". To se radši nemám ptát a nebo si mohu dovolit položit dotaz LIKE '%hule%' (samozřejmě s tím, že databázoví stroj se trochu zapotí)?

A vedel jste, ze, pokud neni na sloupecku index, tak LIKE '%neco%' je asymptoticky stejne narocne jako = 'neco2'? ;-)

Ptat se muzete vzdycky :-) To, zda si to muzete nebo nemuzete dovolit zavisi na spouste dalsich faktoru, zejmena velikosti prohledavanych dat.

o rly? ja doted zil v tom, ze porovnani ma slozitost O(n), kdezto vyhledani podretezce ma samo o sobe v nejlepsim pripade slozitost O(n.log n).

Nerozumím přesně co jste chtěl poznamenat.

Já jsem se snažil o upozornění, že i like '%neco%' prostě svůj smysl má a to i přesto, že jeho vykonání je prostě hodně neefektivní (index mi tu nepomůže) na rozdíl od ='neco' či like 'neco%' (kde index hraje významnou roli).

Je naprosto legitimní umožnit uživateli provádět dotazy (zejména u číselníků) typu like '%neco%'. Mou snahou je však, aby prioritu mělo hledání typu like 'neco%' a pokud chce uživatel like '%neco%' musí to systému říci (například zadáním '*neco'). V praxi jsou pak zejména časté dotazy 'neco%' a pak třeba like 'neco%dodatek%' (kde index roli hraje).

Tvrdit, že užití like '%neco%' koresponduje se špatně navrženou databází není pravda.

Prefix matching (LIKE 'prefix%) je specificky pripad pouzitia LIKE a vacsina databaz sa snazi ho realizovat efektivne.

V pripade vacsieho poctu zaznamov (cokolvek ine nez "konstantny" ciselnik o par 10/100 riadkoch) sa len treba ubezpecit, ze db naozaj pouzije index (zavisi od konkretneho DBMS, pouziteho collation, case (in)sensitivity). Inak to povedie k seq scanu s podobnou cenou ako vseobecny neprefixovy pripad.