Chcąc udostępnić potencjalnym klientom efektywny mechanizm wyszukiwania w bazie towarów, koniecznym stało się skonstruowanie odpowiednich mechanizmów umożliwiających pobranie od internauty interesującej go frazy, przeszukanie bazy danych oraz zaprezentowanie znalezionych pozycji. Pewnym problemem wydaje się być tutaj konieczność połączenia efektywności mechanizmu wyszukującego z możliwościami silnika bazy danych. Większość obecnie istniejących baz danych nie pozwala na wyszukiwanie pełnotekstowe przy wykorzystaniu indeksu, gdy szukana fraza zaczyna się znakiem wieloznacznym w zapytaniu typu „LIKE”. Najnowsze komercyjne bazy danych takie jak ORACLE wspierają ten mechanizm poprzez statyczne utworzenie specjalnych struktur indeksujących pełnotekstowo całe pola tabeli, jednakże jedynie statycznie. Każdorazowe dopisanie krotki do tabeli wymusza ponowne pełne zindeksowanie całości tabeli, co praktycznie wyklucza to zastosowanie w przypadku bazy, gdzie są modyfikowane lub dodawane kolejne rekordy.

Rysunek 7. Główna strona wyszukiwarki towarów.

PostgreSQL posiada bardzo zaawansowane metody i typy indeksów, jednak nie ma możliwości ich użycia w przypadku pełno tekstowego wyszukiwania. Silnik bazy danych jest wtedy zmuszony do wykonania pełnego przejścia po wszystkich krotkach tabeli (tzw. full scan), co drastycznie obniża efektywność tego rozwiązania.

W obecnej fazie rozwoju aplikacji sklepu internetowego zdecydowano się na pewne rozwiązania skutecznie eliminujące wykonywanie pełnych przejść w tabelach. W głównym oknie wyszukiwawczym jednak taki mechanizm musiał tymczasowo pozostać ze względu na konieczność zapewnienia pełnego wyszukiwania nawet kosztem zwiększonego obciążenia systemu i spowolnienia samego procesu. W module ofert przy przeglądaniu gotowych zestawień towarów zastosowano zmodyfikowany mechanizm głównej wyszukiwarki w taki sposób aby nie używać zapytań zaczynających się znakiem wieloznacznym „%” w klauzuli „LIKE”, co spowodowało możliwość użycia przez motor bazy danych indeksów na przeglądanych polach a tym samym wykonywanie całości zapytania w sposób błyskawiczny.

Rysunek 8 — Prezentacja wyników wyszukania towaru.

Chcąc rozwiązać tzw. problem „full text search” czyli pełnotekstowego wyszukiwania korzystającego z indeksów (postaresa1.org/idocs/index.php?indices.html) w przygotowaniu jest pewien model przechowywania nazw towarów w dodatkowej tabeli, ale w taki sposób, aby możliwym stało się zaindeksowanie każdego wyrazu z nazwy towaru. Opracowana koncepcja polega na podziale nazwy towarów na odrębne wyrazy a następnie na zapisanie ich do odrębnych pól w krotce.

Każde pole będzie polem indeksowanym tak więc przy konstruowaniu zapytania możliwym stanie się wykorzystanie w mechanizmie wyszukiwarki odwołania klauzulami „LIKE” bez podawania na początku znaku wieloznacznego „%” a zamianę szukanej frazy na kilka klauzul typu „LIKE ‘towar%’” co pozwoli na użycie indeksów jak w przypadku przeszukania w module ofert. Pole z nazwą towaru i oznaczeniem producenta sumarycznie ma długość 34+19=53 znaki. Zakładając że w skrajnym pesymistycznym przypadku nazwa towaru złożona będzie z pojedynczych liter rozdzielanych spacjami to otrzymujemy około 27 pól

Rysunek 9 — Prezentacja wyszukiwania predefiniowanego rodzaju towarów.

potrzebnych do rozbicia na wyrazy (53/2=26+1). Tak więc przyjmujemy, że 30 pól jest liczbą wystarczająca w zupełności do przechowania całej nazwy towaru w rozbiciu na wyrazy. Spacje nie są przechowywane bowiem służą jako znak, według którego dokonujemy rozbicia na części składowe. Do kolejnych pól rekordu wpisujemy kolejne wyrazy z nazwy towaru a sama treść zapytania wykonującego wyszukanie z wykorzystaniem indeksów przyjmie wtedy przykładową postać:

SELECT * FROM subtowary WHERE pole1 LIKE ‘szukana_fraza%’ OR pole2 LIKE ‘szukana_fraza%’ OR…..

Zakładamy oczywiście że szukana fraza jest pojedynczym wyrazem, a w przypadku, gdy jest to kilka wyrazów wykonujemy kilka takich zapytań dla każdego z wyrazów, składanych następnie w jeden zestaw wyników. Powyższy projekt rozwiązania problemu pełnych przejść po tabeli wydaje się być optymalnym do tego celu rozwiązaniem i będzie testowo zastosowany w aplikacji sklepu internetowego w najbliższym czasie.

Kod źródłowy wyszukiwarki

Mechanizm wyszukiwarki został wbudowany w różne strony serwisu internetowego firmy. W momencie gdy powstawał, język PHP nie posiadał uniwersalnej klasy obiektów służących do odwołania do bazy danych. Każdy typ bazy danych wymagał użycia innego zestawu poleceń. Chcąc maksymalnie uniezależnić się od samej bazy zastosowano uniwersalne definicje funkcji odwołujących się do baz. Wykorzystano do tego celu bibliotekę phpDB której autorami są J. Thong i C. Fonk (phpdb.linuxbox.com) pozwalającą na zamaskowanie metod odwołań do baz MySQL, MSQL, PostgreSQL, Microsoft SQL Server, Sybase na jednakowe funkcje, co pozwala na łatwą wymianę silnika bazy na inny bez konieczności zmian w kodzie źródłowym. Obecnie rozwijana jest przez autorów języka PHP, klasa uniwersalnych funkcji, metod i obiektów pozwalająca na uniknięcie problemów związanych z koniecznością przeróbek kodu w takich przypadkach. Projekt jest obecnie w bardzo wczesnej fazie rozwoju jednakże fakt tworzenia go przez ekipę tworzącą PHP gwarantuje, że wkrótce możliwym będzie zastosowanie go w systemach produkcyjnych. Nosi on nazwę „PEAR: the PHP Extension and Application Repository”. Poniższy listing prezentuje i omawia kod php wyszukiwarki. Niektóre linie zostały sztucznie podzielone na krótsze ze względu na ich długość, co oznaczono znakiem „\” (jednakże on sam w kodzie oryginalnym nie może występować). Listing zawiera komentarze świadczące o zespołowej pracy nad powstającym kodem oraz podział zadań na kod dostępu i obsługi bazy danych oraz kod dynamicznego generowania strony na podstawie pobieranych z bazy danych rekordów.