wyszukiwarka, wydajna, z prawdziwego zdarzenia ;) |
Tematy na forum Pro mogą zakładać jedynie moderatorzy. W otwartych tematach może pisać każdy, kto ma coś fachowego do powiedzenia. Wszystkie posty nie wnoszące nic do tematu będą natychmiast usuwane, a ich autorzy dostaną ostrzeżenie.
Jeśli uważasz, że jakiś temat jest warty dyskusji na tym forum, zgłoś go w temacie Propozycje.
wyszukiwarka, wydajna, z prawdziwego zdarzenia ;) |
4.12.2005, 00:48:17
Post
#1
|
|
Grupa: Zarejestrowani Postów: 179 Pomógł: 0 Dołączył: 8.10.2004 Ostrzeżenie: (0%) |
Witam,
wiem, że takie tematy już były, ale nie znalazłem w nich żadnych konkretów. Jak podeszlibyście do problemu zbudowania mechanizmu wyszukiwarki dla systemu, który nierzadko może obsługiwać spore ilości danych (w wielu tabelach)? Interesuje mnie wszystko na ten temat - linki, artykuły, tutoriale. Spotkałem się już w kilku aplikacjach z rozwiązaniem, które wyglądało mniej więcej tak: treść tabeli, np. articles jest dzielona na słowa, np tekst: Cytat To jest przykładowa treść artykułu Zostanie podzielony na tablicę:
Słowo "to" jest traktowane jako tzw. common word i pomijane. Te słowa są wrzucane do osobnej tabeli, która ma mniej wiecej taką strukturę: Kod word_id word_text Do tego jest jeszcze jedna tabela, która łączy artykuł ze słowami: Kod article_id word_id Rozwiązanie ciekawe, ale zastanawia mnie, jak to jest z jego wydajnością. O ile liczba słów jest ograniczona, to druga tabela może się nieźle rozrosnąć. Pisał już ktoś coś takiego? Jakie są wasze sposoby na problem wyszukiwarki w CMSach? |
|
|
26.03.2007, 23:24:19
Post
#2
|
|
Grupa: Zarejestrowani Postów: 793 Pomógł: 32 Dołączył: 23.11.2006 Skąd: Warszawa Ostrzeżenie: (0%) |
pawkow to rozwiązanie jest kiepskie, ponieważ przy pojawieniu się nowego artykułu, nie masz możliwości usunięcia bufora. A jakbyś to robił, to by było takie samo obciążenie, jak przy użyciu samego LIKE. Przy każdym wybraniu musiał byś rozdzielać dane, co też generuje obciążenie.
Jeszcze sam nie wnikałem w ten problem, ale przy tym co się chwile zastanowiłem, to chyba najlepsze rozwiązanie to word | id_article przy czym unikalne jedynie mogło by być połączenie obu. Przy założeniach szukania samego artykułu bez cytatu. Bo chyba jednak problem nie może być rozwiązany aby był mało obciążający pamięciowo i obliczeniowo. -------------------- Algorytmy w PHP, czy ktoś o tym słyszał?
Dlaczego tak mało kobiet programuje? ponieważ nie zajmują się głupotami. |
|
|
25.06.2010, 17:03:41
Post
#3
|
|
Grupa: Zarejestrowani Postów: 48 Pomógł: 3 Dołączył: 7.12.2007 Ostrzeżenie: (0%) |
pawkow to rozwiązanie jest kiepskie, ponieważ przy pojawieniu się nowego artykułu, nie masz możliwości usunięcia bufora. A jakbyś to robił, to by było takie samo obciążenie, jak przy użyciu samego LIKE. Przy każdym wybraniu musiał byś rozdzielać dane, co też generuje obciążenie. Jeszcze sam nie wnikałem w ten problem, ale przy tym co się chwile zastanowiłem, to chyba najlepsze rozwiązanie to word | id_article przy czym unikalne jedynie mogło by być połączenie obu. Przy założeniach szukania samego artykułu bez cytatu. Bo chyba jednak problem nie może być rozwiązany aby był mało obciążający pamięciowo i obliczeniowo. Sedziwoj, nie jestem przekonany co do tego co mówisz. Znaczy oczywiście nie pozbywamy się obciążającego LIKE'a, ale można zrobić relację many-to-many zamiast takiej dziwnej kolumny z separatorami | i przy ponownym wyszukiwaniu takim zapytaniem z LIKE określić w WHERE tylko te rekordy których czas utworzenia lub modyfikacji jest późniejszy niż czas utworzenia rekordu wyszukiwania. To tak bez wdawania się w niepotrzebne szczegóły. Za to problem który widzę to dodatkowe obciążenie bazy przy zapisywaniu wyników wyszukiwania, literówki popełnione przez wyszukujących i tak dalej pawel_ - dzięki za ten skrypt, a właściwie za metodę z tymi słownikami Odnośnie budowania indeksu słów, takie rozwiązanie stosuje np. phpBB. |
|
|
Wersja Lo-Fi | Aktualny czas: 20.06.2024 - 01:32 |