Czykolumna LIKE 'String' jest dużo wolniejsze od porównywania liczb? Bo wydaje mi się, że wolniejsze to na pewno jest. Czy na siłe stosować wszedzie w bazie ID w postaci liczby, które wskazuje na jakiś napis, czy wstawiać od razu ten napis?
0
0
LIKE jest wolne. Nie ma co do tego watpliwosci. Nalozenie indeksu pomoze, ale nie zda sie na wiele jezeli rekordow bedzie b. duzo.
Co do Twojego pytania - stosuj osobna tabele z ID. Nazywa sie to procesem normalizacji.
Przykladowo masz w tabeli wstawiac miejsce zamieszkania uzytkownika. Tworzysz kolumne user_location:
user_location SMALLINT(6)
Nastenpie kolejna tabele - np. location:
location_id SMALLINT(6)
location_text VARCHAR(100)
W user_location przechowujesz tylko ID z tabeli location (klucz obcy). Rozumiesz?
0
Rozumiem :) Dzieki za odpowiedź.
0
Adam Boduch napisał(a)
Co do Twojego pytania - stosuj osobna tabele z ID. Nazywa sie to procesem normalizacji.
No dobrze, to ja mam takie pytanie z ciekawości.
Jeśli chcemy wyszukać użytkowników mieszkających gdzieś tam, to czy wykonanie podzapytania przeszukującego tabelę useres_location, które przez LIKE wyszukuje miejsca zamieszkania, a potem zapytania w tabeli users dla kluczy obcych zwróconych przez tamto podzapytanie będzie szybsze?
0
Może być szybsze, ale nie musi. Rozważ sytuacje:
- masz milion userów i 100 miejsc zamieszkania
- masz milion userów i pół miliona miejsc zamieszkania
pzdr,
0
A jeśli mam tysiąc userów i tysiąc miejsc zamieszkania? Bo jak zrozumiałem o taką sytuację pyta autor, skoro używa słów "na siłę".
0
somekind napisał(a)
A jeśli mam tysiąc userów i tysiąc miejsc zamieszkania? Bo jak zrozumiałem o taką sytuację pyta autor, skoro używa słów "na siłę".
W takiej sytuacji nie ma sensu rozbijać na 2 tabelki. Jeśli ograniczenie jest jest typu LIKE %costam%, to lepiej zrobić tablescana na tabeli i wyszukiwać %costam% niż robić tablescana na tabelsce (id, miejsce zamieszkania), a później dodatkowo złączenie z tabelką użytkowników.
Rozbijanie na 2 tabele ma sens wtedy, gdy liczba użytkowników >> liczba miejsc zamieszkania.
Nie wiem jak ma się sprawa z indeksowaniem pełnotekstowym, ale z tego co pamiętam to np. w Oracle stosuje się do tego inne klauzule niż LIKE (bodajże CONTAINS).
pzdr,
0
Dorzucę od siebie tylko tyle że niektóre enginy (np FB) nie skorzystają z indeksu gdy napiszesz LIKE '%xxx%' ale skorzystają gdy użyjesz STARTING WITH (czy coś takiego). Oczywiście wtedy % na początku odpada.
0
To i ja dorzuce swoje 3 grosze:
- Like jest wolniejsze od =
- Stosuj zawsze ID
- Porownywanie stringow czy tez liczb mozemy uznac za tak samo szybkie po nastepujacymi warunkami:
a) masz zalozony na kolumnie po ktorej szukasz index
b) porownujesz kolumny poprzez = czyli.where kolumna = 'string'
0
No to ja tez cos od siebie:
w porownaniach like uzywaj zawsze opertorow SARG like 'xxx%' zamiast like '%xxx%'
przy porownywaniu stringow '=' uzywaj CHARINDEX(string1) = charindex(string2) or string1 = string2.