Witam,
Mam serwis na którym chcę umieścić opcję szukaj w serwisie. Wszystkie dane, artykuły etc są zapisane w bazie danych. Jak zrobić to optymalnie? Przez widoki? Może jakieś wskazówki ?
Witam,
Mam serwis na którym chcę umieścić opcję szukaj w serwisie. Wszystkie dane, artykuły etc są zapisane w bazie danych. Jak zrobić to optymalnie? Przez widoki? Może jakieś wskazówki ?
Jaka baza?
musisz to zrobić tak aby
explain plan
Baza danych jest prosta. Strona jest o turystyce danego regiony więc dużo tabel ale wartości w tabelach prawie identyczne (wartości = nazwy etc).
fajnie
-Jaka baza?
-Prosta
Umarłem...
Tak, baza jest prosta, jak dwa metry drutu w kieszeni :P
Czyli lepiej stworzyć jedną tabelę o silniku myisam? niż kilka tabel np: ciekaw_miejsca, rekreacja, turystyka, kultura, galerie, noclegi, gastronomi etc ? Lepiej dać to na jedną tabele? Tab na MyISAM szybicej przeszukuje SQL niż na InnoDB. Może to i pomysł, sporo by to dało ;) Do tych tabel nie mam żadnych relacji wiec InnoDB, jest niepotrzebne ;) Ale znowuż mam sporooo takich działów, i jeszcze więcej artykułów do nich (rekordów).
poza tym ? Co to za różnica? Jeśli mam dużo krotek to nie lepiej powrzucać je do kilku tabel ? I dzięki temu zmniejszamy ilość krotek ( i czas wyszukiwania)? A tak mamy jeden wielki kocioł, suuuper. Każdy dział jest na innej zakładce, więc każde kliknięcie powoduje przeszukiwanie w bazie... To po co są widoki w SLQu ? :/ Koks, dawaj... ?
Jeśli taki sposób jest dobry? TO jeszcze pytanie jak już mam taki jeden duży wór ze wszystkimi artykułami. To jak znaleźć ten podciąg (stringa) ? Jak napisać zapytanko w SQL? np jeśli szukany string to 2 -4 słowan?
masz artykuły/teksty różnego typu, ale to wszystko są teksty. robisz jedną tabelkę trzymającą id, typ i tekst (i ewentualne inne dane takie jak data utworzenia i autor, data i autor ostatniej zmiany itp). robisz sobie indeks fulltekst na tej jednej tabeli lub organizujesz i optymalizujesz wyszukiwanie w inny sposób, ale nadal na tej jednej tabeli. masz wszystko ładnie w jednym miejscu, a nie porozrzucane po całej bazie, dzięki czemu poprawki i optymalizacje robisz raz w jednym miejscu, a nie dwudziestu.
do tego jedna (1:N) lub dwie (M:N) tabele na załączniki - linki do zdjęć i innych plików tego typu. tabela z użytkownikami, kilka innych o których o tej porze nie jestem w stanie pomyśleć - i już.
"jeden wielki kocioł" to dane podobnego typu porozrzucane w wielu miejscach. powoduje to złamanie reguły DRY (don't repeat youself), problemy ze spójnością kodu i danych, utrudnia robienie poprawek i zmian.
"Każdy dział jest na innej zakładce, więc każde kliknięcie powoduje przeszukiwanie w bazie" - tego nie rozumiem, co to ma do rzeczy? jeśli każde kliknięcie powoduje "przeszukiwanie w bazie", to masz albo spieprzony serwis, albo bazę danych. tak czy inaczej jeśli reakcja na kliknięcie na stronie wymaga biegania po bazie danych, to jakie ma znaczenie z punktu widzenia wydajności, czy będzie w niej dużo, czy mało tabel? jeśli boisz się, że dużo danych w jednej tabeli oznacza zauważalnie dłuższy czas wykonywania zapytań, to poczytaj o indeksach (i ewentualnie o partycjonowaniu tabel) oraz o planie zapytania (execution plan).
widoki również nie mają nic do rzeczy, operują na danych z istniejących tabel, mają za zadanie ułatwiać wyciąganie informacji (w specyficznych przypadkach w ogóle je umożliwiają). jeśli są zbędne, to nie używa się ich, a w Twoim przypadku mam wrażenie, że tak właśnie jest.
"jak znaleźć ten podciąg (stringa) ? Jak napisać zapytanko w SQL? np jeśli szukany string to 2 -4 słowan?" trzy sposoby: