[MySQL] -Łączenie tabel w najefektywniejszy sposób

0

Mam pytanie jaki jest najefektywniejszy sposób łaczenia kilku tabel (>3). Obecnie użuwał łączenie LEFT JOIN. Ale czytałem, że to rozwiązyanie powinno się stosować tylko przy małych tabelach.

Mam jeszcze jedno pytanie, jestem samoukiem, więc na bazach danych, czyli SQL znam się tyle ile znalazłem w internecie. Mam pewien projekt przygotować. Moim zadaniem jest stworzenie bazy danych i ich obługa w PHP. Zastoswałe kilkanaście tabel.Tabele dla użytkownika podzieliłem na częśc do logowania, czyli podst. login,haslo,email i profil w osobnej tabeli. Dane umieszczane w serwisie równiez podzieliłem, czytałem że jest to zalecane zewzględu na optymalizację działania pracy serwera. Natomiast i członek naszego zespołu ort! się z moim zaplanowanie, twierdzi że kilka tabel można połaczyć w jedną a najbardziej chodzi mu o wyświetlanie zawartości tematycznej w serwisie. ort! tabela zawierająca daną kategorie, temat postu do szybszego wyszukiwania, a tabele z informacjami dodatkowymi zamieściłem w osobnej tabeli, pola typu VARCHAR(255), TEXT.

Mam więc pytanie czy do optymalizacji tabeli nie zależna jest jakie pola wystepują i czy to wszytsko połączyć, czy jednak lepiej rozdzielić te dwa elementy?

0
Linix napisał(a)

Mam pytanie jaki jest najefektywniejszy sposób łaczenia kilku tabel (>3). Obecnie użuwał łączenie LEFT JOIN. Ale czytałem, że to rozwiązyanie powinno się stosować tylko przy małych tabelach.

LEFT JOIN powinno się stosować tam, gdzie jest wymagane. Inaczej - w pewnych wypadkach LEFT JOIN nie da się zastąpić (znaczy da się zastąpić ale nie będzie to szybsze a i wyglądać będzie dziwnie). Czyli czy stosujesz LEFT JOIN czy INNER JOIN czy jeszcze coś innego zależy od tego jakie dane chcesz wyciągnąć. Poza tym każda normalna baza ma coś takiego jak EXPLAIN - polecam poczytać http://dev.mysql.com/doc/refman/5.0/en/explain.html i zobaczyć jak będzie się zachowywało zapytanie a następnie przyjrzeć się bliżej najbardziej czasochłonnym elementom

Mam jeszcze jedno pytanie, jestem samoukiem, więc na bazach danych, czyli SQL znam się tyle ile znalazłem w internecie. Mam pewien projekt przygotować. Moim zadaniem jest stworzenie bazy danych i ich obługa w PHP. Zastoswałe kilkanaście tabel.Tabele dla użytkownika podzieliłem na częśc do logowania, czyli podst. login,haslo,email i profil w osobnej tabeli. Dane umieszczane w serwisie równiez podzieliłem, czytałem że jest to zalecane zewzględu na optymalizację działania pracy serwera. Natomiast i członek naszego zespołu niezgadza się z moim zaplanowanie, twierdzi że kilka tabel można połaczyć w jedną a najbardziej chodzi mu o wyświetlanie zawartości tematycznej w serwisie. Jestam tabela zawierająca daną kategorie, temat postu do szybszego wyszukiwania, a tabele z informacjami dodatkowymi zamieściłem w osobnej tabeli, pola typu VARCHAR(255), TEXT.

Mam więc pytanie czy do optymalizacji tabeli nie zależna jest jakie pola wystepują i czy to wszytsko połączyć, czy jednak lepiej rozdzielić te dwa elementy?

ogólnie to jest tak - baza, kandydująca do miana dobrej jest w 3 postaci normalnej, jeśli baza jest w 1 lub 2 PN na pewno nie jest optymalna i dobra. Bardzo często spotyka się bazy w tzw. 2 i pół PN - polega to na tym, że mając już 3 PN bazy i wiedząc jakie dane będą składowane i (co ważniejsze) jakie dane będą najczęściej wyciągane dodaje się do bazy pewne dane nadmiarowe, które nie zwiększą ilości danych w jakiś zauważalny sposób a prawdopopodobnie w znaczny sposób przyśpieszą wybieranie danych z bazy. Takie nadmiarowe dane to np. pole z rokiem obok pola z pełną datą - nie trzeba wyciągać roku (jeśli jest często potrzebny) z daty, a i indeks założony na polu z rokiem (np, integer) będzie zachowywał się inaczej niż na polu z datą (date lub timestamp).

Tak więc bez w miarę szczegółowego opisu co baza ma przechowywać, co będzie z niej wyciągane, przypuszczalnego obciążenia i przyrostu danych odpowiedz na Twoje pytanie jest raczej niemożliwa bo to czy lepiej coś podzielić czy zostawić razem zależy od konkretnego projektu

1 użytkowników online, w tym zalogowanych: 0, gości: 1