kłopot z LIKE Opcje

[acztery]

Witam mam kłopot i nie mam pomysłu, chodzi o LIKE

mam w bazie ok 700 tagów

np:

łysienie
łycienie plackowate
łysienie analogiczne

i teraz

jezeli tak LIKE '%łysienie%' znajduje te 3 a ma tylko ten 1... i analogicznie z innymi

[nospor]

znajduje te 3 a ma tylko ten 1

jesli moglbyc to przetlumaczyc na nasz, polski, to byloby milo

[acztery]

ale ok jaśniej

mam np takie dane w bazie

łysienie
łycienie plackowate
łysienie analogiczne

jak wykonam .... Tag LIKE '%łysienie%' ..... to mysql zwróci mi te trzy rekordy ( patrz wyżej ) a ma zwrócić dokładnie tylko te gdzie wystepuje tylko słowo łysienie bez żadnych przyrostków...

Ten post edytował acztery 23.07.2008, 20:04:31

[phpion]

To wywal te % czyli:

[SQL] pobierz, plaintext 
Tag LIKE 'łysienie'
[SQL] pobierz, plaintext 

ale to wtedy mozna spokojnie zastąpić:

[SQL] pobierz, plaintext 
Tag = 'łysienie'
[SQL] pobierz, plaintext 

O to chodziło?

[acztery]

Sprawa wyglada tak.

Troszkę to opisze bo skrawki wiadomości mogą mało Wam mówić..


Wiec. Po pierwsze mam bazę tagów w 1 tabeli , w 2 tabeli sa artykuły. Każdy artykuł może mieć swoje tagi.

I teraz w panelu admina mamy select gdzie jest lista tagów i zaznaczone sa te które są przypisane do danego art.

jezeli w liscie zaznaczymy tag łysienie analogicznie to póżniej mamy zaznacozny tez tag łysienie.

Tagi dla art przechowuje w 1 kolumnie o nazwie Tag oddzielone znakiem "|"..

PS

problem rozwiązałem

... Tag LIKE '%lysienie|%'

to tyle dzieki za pomoc..

[nrm]

masz żle zaprojektowaną bazę

[acztery]

Normanos czy ja wiem juz w tej chwili pobranie listy art wiąze się z połączenie z 3/4 innymi tabelami jak dojdzie do tego jeszcze 1 tylko poto aby obsługiwać tagi to nie wiem czy to wydajne rozwiązanie.

Tak to tylko operacja na tagach odbywa sie przy dodaniu/edycji art

a tak za kazdem razem musial bym analizowac tabele z tagami.

PS troszkę zamieszania zrobiłem

normanos sugerujesz ze do obsługi tagów potrzeba 3 tabele

1. tabela z art
2. tabela z wszystkimi tagami w bazie
3. trabela z tagami ktore sa przypisane do danych art.

Ten post edytował acztery 23.07.2008, 20:46:10

[nospor]

nie musisz mentrkować...

jedynie grzecznie poprosilem o lepszy opis, bo te skrawki na poczatku jak sam przyznalez nic nie mowily. Pominoles rowniez tak wazny szczegol jak trzymasz dane w bazie. Nie wiem oco wiec sie obruszasz...

normanos sugerujesz ze do obsługi tagów potrzeba 3 tabele

1. tabela z art
2. tabela z wszystkimi tagami w bazie
3. trabela z tagami ktore sa przypisane do danych art.

Tak, zdecydowanie lepsze rozwiązanie od tego co masz teraz

[acztery]

i bede łączył się z 6 tabelami poto by wylistowac rekordy.. ? może tak zrobie ale teraz to zostawie chodzi szybko..

co do mentrkowania usunołem ten tekst,a ty to wygrzebałeś...

pozdro

[nrm]

tak, tak twierdze to zresztą klasyczny przypadek wiele-do-wielu.

co to jest dodatkowe 1 czy 2 pytania sql? Nic, beknięcie po obiadku...

[acztery]

spoko ale czy to wiele-do-wielu nie bedzie miało wpływu na czas...

[nospor]

co do mentrkowania usunołem ten tekst,a ty to wygrzebałeś...

Nie wygrzebalem a przeczytalem w mailu, ktory dostalem

i bede łączył się z 6 tabelami poto by wylistowac rekordy.. ?

Nie wnikam z iloma jeszcze tabelami się łączysz. Zgadzam się jedynie z normanosem ze twoja obecna struktura na tagi jest nienajlepsza i napewno nie szybsza od rozwiązania z oddzielnymi tabelami. Pozatym Twoje rozwiązanie jest nieelaganckie, nie daje takiej mozliwosci jakie dają relacje na dobrze zrobionej bazie

[manro]

Jeżeli zależy ci tak bardzo na szybkości bardziej wydajne będzie korzystanie z trzech tabel i instrukcji porównania = (znak równa się)
w celu wyszukania odpowiedniego tag'a

Kod

... WHERE Tag = 'łysienie' ...

Wykonując SELECT'a z instrukcją LIKE zmuszasz bazę danych do przeszukania wszystkich wierszy tabeli za każdym
razem gdy wykonujesz takie zapytanie. Jednak, że różnicę czasową odczujesz dopiero przy tabelach z dużą ilością wierszy.

Na danych atomowych możemy założyć indeksy które znacznie skrócą czas przeszukiwania tabeli w poszukiwaniu odpowiedniej wartości.

Poza tym separując dane w jednej kolumnie znakiem | łamiesz zasadę atomowości danych dlatego projekt nie jest do końca właściwy

I co najważniejsze wszystkie dane pobierasz w jednym dobrze skonstruowanym zapytaniu SQL,
nie ma sensu tracić czasu na ponowne wysłanie żądania i czekaniu na jego odpowiedź.