Chcialbym stworzyc system slow kluczowych w stylu np. youtube.com, pudelek.pl (moj faworyt:P) i wielu wielu innych sajtow - duzo sie tego porobilo. W skrocie chce takiej funkcjonalnosci, zeby artykuly mialy przypisywane recznie slowa kluczowe i aby potem na podstawie slow kluczowych wyszukiwac artykuly podobne, tworzyc indeksy wszystkich artykulow z przypisanym danym slowem etc.

Platforma to mysql. Jaka strukture bazy slow kluczowych wybrac? Czy do kazdego artykulu robic jedno pole tekstowe po prostu z oddzielonymi spacjami keywordami i stworzyc na tym polu indeks fulltext, czy tez raczej zrobic wielka baze relacji id|slowo|artykul, czyli np. dla artykulu o ID 15 rekordy:


Nieee wiem czy to nie powinno trafic do dzialu o mySQL, ale to nie jest tylko kwestia bazy - chodzi mi rowniez o to jak na platformie php potem w sposob wygodny i wydajny to obslugiwac.

Możesz stworzyć w bazie tabelę o następujących polach:

- idkeyword (int)
- idarticle (int)
- skeywords (text)

W polu keywords przechowujesz słowa kluczowe w następującej formie:

;slowo1;slowo2;slowo3; itd.

Aby sprawdzić czy szukane przez użytkownika słowo jest przypisane do danego artykułu w zapytaniu SQL uzywasz like.

[PHP] pobierz, plaintext 
<?php
$sql = "select * from tabarticle where idarticle = ".$idarticle." and skeywords like ';".$zmienna.";'";
?>
[PHP] pobierz, plaintext 

W zmiennej $zmienna zawiera szukane słowo.

3 standardowe tabele dla relacji wiele do wielu (tagi, artykuly, artykuly_tagi ( RoR rzondzi* -- tabele w kolejnosci alfabetycznej. Koniec malej dygresji) -- bedziesz mial baze znormalizowana. Jak bedzie za wolne to dodaj liczniki artykulow do tabeli z tagami, zeby co chwile nie liczyc count( * ).


Przenosze na MySQL, bo jest to kwestia zaprojektowania bazy danych

Co byś trzymał w poszczegolnych tabelach?

googlenie boli: http://www.google.com/search?hs=aaw&hl...=Szukaj&lr=

Nie boli. Nie pytam się co to jest i jak działa relacja jeden do wielu, tylko jakbyś te tabele zaprojektował.

Like to zabojstwo, to chyba nie jest droga - juz lepiej fulltext

dr_bonzo
Brzmi logicznie, to powinno byc najwydajniejsze rozwiazanie. Fulltext jest chyba prostszy do wdrozenia, ale napewno proste indeksy na INT beda wydajniejsze no i oszczedzimy sporo miejsca.

Dzieki.

Na jakiej podstawie piszesz, że like to zabójstwo. Co ma wspólnego like z fulltext?

Zapytanie w stylu

[SQL] pobierz, plaintext 
SELECT id FROM artykuly WHERE keywords LIKE '%;ZMIENNA;%'
[SQL] pobierz, plaintext 

przy obciazeniu kilkuset zapytan na minute przy bazie powiedzmy 20k rekordow zabije najpotezniejszy serwer. Tworzac na polu keywords indeks fulltext i szukajac potem po tym indeksie mozna to robic na przyslowiowym celeronie. Zapytania po indeksach zawsze beda wydajniejsze, funkcja LIKE musi przeczesac wszystkie rekordy.

Ok. Załóżmy, że masz książke telefoniczną. Wyszukujesz po imieniu, nazwisku, dziale czy stanowisku pracy. Chciałbyś, żeby użytkownik nie musiał wpisywać całej nazwy działu czy stanowiska tylko napisał np. dzial k a system odnajdzie mu wszystkie telefonu które pasują do tego wyrażenia, np. Dział Kadr, Dział Kontroli, Dział K... itd.

Jak to zrobisz bez LIKE ?

Po pierwsze, to jest zupelnie inny problem
Po drugie, wyszukiwanie FULLTEXT w MySQL ma mozliwosc dopelnienia

[SQL] pobierz, plaintext 
SELECT id FROM tabela WHERE MATCH ('pole') AGAINST ('K*' IN BOOLEAN MODE)
[SQL] pobierz, plaintext 

Tylko ze nie wiem, czy w tym wypadku przewaga wydajnosciowa nad LIKE jest tak ogromna jak przy zwyklym "serczu". Ale zachecam do stosowania indeksow fulltext, moze oszczedzic wymiany sprzetu kiedy wszystko przestaje dzialac

Gdzie znajde (dobrze byłoby po polsku) jakieś szczegóły o tajemniczym FULLTEXT? Na ggooglunic ciekwaego nie znalazłem

Google jest pelne artykulow i tutoriali w jezyku angielskim, natomiast po polsku nigdy nic na ten temat nie znalazlem.