http://stronger.epsi.pl/2008/06/10/uniwersalne-wyszukiwanie/Wpisy z dziennika internetowego Jogger, wspomaganego przez JabberaMon, 21 May 2012 09:56:03 +0200JoggerPLhttp://stronger.epsi.pl/2008/06/10/uniwersalne-wyszukiwanie/#c1184793Jeżeli dobrze rozumiem, to w wyniku takiej implementacji wszelkie dane, które chcemy przeszukiwać są dublowane - znajdują się w swojej własnej tabeli (np. z postami, tagami etc) oraz w tabeli z danymi do przeszukania? Zapewne jest to i szybsze, bo przeszukujemy jedną tabelę, ale ja zostanę na razie przy swoim ISearchable i function search($string) bo DAO do mnie nie przemawia :)Tue, 10 Jun 2008 18:47:17 +0200http://stronger.epsi.pl/2008/06/10/uniwersalne-wyszukiwanie/#c1184793http://stronger.epsi.pl/2008/06/10/uniwersalne-wyszukiwanie/#c1184815Zasadniczo tak, choć nie zawsze. Jeśli w blogu zezwalamy na składnię HTML to z pewnością nie chcemy aby znaczniki łapały się do wyników wyszukiwania. Do tego celu metodę BlogPost::updateSearchEngine należałoby lekko zmodyfikować dodając strip_tags dla pola body.Co do wydajności - moje zdanie co do wszelkiej optymalizacji poznasz we wpisie http://stronger.jogger.pl/2008/06/02/faszysci-optymalizacji/DAO? - jeszcze przemówi ;-)Tue, 10 Jun 2008 18:58:31 +0200http://stronger.epsi.pl/2008/06/10/uniwersalne-wyszukiwanie/#c1184815http://stronger.epsi.pl/2008/06/10/uniwersalne-wyszukiwanie/#c1184902Hm, sprytne z tym wycinaniem znaczników - w takim wypadku jest to duży inplus.Jeżeli chodzi o optymalizację - cóż, zdanie ciekawe nie będę się spierał ;-) Tym nie mniej gdybym u siebie zastosował takie rozwiązanie jak opisujesz to przy przekształcaniu wyników na tabele, modułu i strony wyszło by na to samo pod wzg. prędkości pewnie :-)Tue, 10 Jun 2008 20:31:26 +0200http://stronger.epsi.pl/2008/06/10/uniwersalne-wyszukiwanie/#c1184902