Jedna duża tabela, czy kilka mniejszych?, Optymalizacja bazy danych Opcje

[awakening]

Witam,

jestem na etapie projektowania struktury bazy danych dla dosyć dużego serwisu (baza obiektów turystycznych) i zastanawiam się czy dane jednego obiektu lepiej przechowywać w jednej dużej tabeli czy w kilku mniejszych (dokładnie jak rozplanowałem to wyszło mi 8 małych), do wyświetlenia kompletnego wpisu potrzebny będzie dostęp do 7 z 8 tabel + 3 z danymi stałymi (z których będą pobierane np. nazwy województwa itp. - w opisie obiektu będzie tylko id rekordu z nazwą województwa), ale np do wyświetlenia wyników wyszukiwania już tylko 4-5 + 2-3 z danymi stałymi. Najkorzystniej zapewne byłoby to zrobić właśnie w ten sposób tylko jestem ciekaw na ile pobieranie danych z różnych tabel w jednym zapytaniu jest mniej efektywne od pobierania danych z jednej dużej tabeli? Gdybym zrobił wszystko w jednej tabeli miałaby ona ok 40 kolumn, więc wydaje mi się, że jest to bezsensu.

Co do ilości zapytań to zdecydowanie większy nacisk kładę na ograniczenie ich liczby przy pobieraniu danych z bazy niż przy dodawaniu (do dodania jest taka liczba danych, że to i tak pożre od 10 do 100 zapytań dla jednego obiektu, ale obiekty będą dodawane stosunkowo powoli).

Dzięki serdeczne za pomoc
Maciek

[muniekw]

Jak dla mnie lepiej jest używać kilku mniejszych tabel. Przy większej ilości użytkowników przetwarzanie jednej większej tabeli może być sporym obciążeniem dla bazy.

[wookieb]

A przy ich wyszukiwaniu trudniej przeszukac wszystkie tabele. Wiec lepsza jedna duza.

[phpion]

Może więc zastosować kilka mniejszych tabel (np. ze względu na normalizację bazy danych) oraz utworzyć widok łączący te tabele (ze względu na wygodę użytkowania)?

[dr_bonzo]

@muniekw:

Jak dla mnie lepiej jest używać kilku mniejszych tabel. Przy większej ilości użytkowników przetwarzanie jednej większej tabeli może być sporym obciążeniem dla bazy.

O_O - a to od kiedy? ze niby szybiej sie wykona siedmiotabelowy join niz przegladanie jednej tabeli?


@phppion
No ale widok to nic innego jak skrot do SELECTa, ulatwia pisanie zapytanek a nic nie przyspiesza.
DO szukarki mozesz sobie przygotowac index w jednej tabeli - tak zebys tylko ja przeszukiwal, a do wyswietlania listy obiektow - albo skorzystaj z indeksu albo juz z joinow.

[awakening]

Jakiś podział na tabele na pewno będę musiał zastosować gdyż np. do jednego obiektu może być przypisanych kilka zdjęć, lub atrybutów (nawet kilkadziesiąt), więc nie ma opcji żebym tworzył oddzielną kolumnę w tabeli głównej dla każdego z nich.

Mówicie żeby utworzyć jeszcze jedną tabelę opisującą dokładnie relacje, ale problem będzie gdy np jeden rekord w tabeli głównej w polu powiedzmy 'obrazek' będzie musiał przekazać id kilkunastu obrazków z tabeli 'obrazki' (sytuacja gdy do jednego obiektu przypisanych jest kilka zdjęć, a info o tych zdjęciach umieszczone jest w oddzielnej tabeli z id obiektu)

[muniekw]

Chodzi mi o to, że nie sztuką jest wszystko wpakować do jednej tabeli i tylko na niej operować. Istnieje przecież coś takiego jak postacie normalne.

@dr_bonzo

O_O - a to od kiedy? ze niby szybiej sie wykona siedmiotabelowy join niz przegladanie jednej tabeli?

Z tym się zgodzę, że złączenia 7 tabel będą się wolniej wykonywały niż operacje na jednej tabeli.

Ten post edytował muniekw 15.06.2009, 09:15:22

[awakening]

Czyli chyba najbardziej optymalnym rozwiązaniem będzie stworzenie dodatkowych tabel tylko dla danych, które wymagają kilku rekordów (zdjęcia, atrybuty itp.), dobrze myślę?

Ten post edytował awakening 15.06.2009, 09:37:20

[muniekw]

Według mnie poczytaj sobie o postaciach normalnych i myślę, że znajdziesz to czego szukasz, bo możemy dyskutować o tym, która metoda jest lepsza, ale tak na prawdę Ty sam wiesz najlepiej jakich Ci potrzeba tabelek i do czego mają być one używane, a jak poczytasz sobie o postaciach normalnych to tam jest napisane czym charakteryzuje się dobrze stworzona baza i jak powinna być prawidłowo zaprojektowana.

[awakening]

Poczytałem i z tego co wyczytałem, to będę musiał zrobić podział na jeszcze większą ilość tabel

[muniekw]

Wiem, że zaprojektowanie dobrej bazy danych dla większych serwisów wiąże się niestety z dużymi problemami, aby wszystko było dobrze zrobione, ale nie martw się. Będziesz mieć bardzo optymalną bazę

Ten post edytował muniekw 15.06.2009, 10:42:13

[dr_bonzo]

Chodzi mi o to, że nie sztuką jest wszystko wpakować do jednej tabeli i tylko na niej operować. Istnieje przecież coś takiego jak postacie normalne.

@dr_bonzo
Z tym się zgodzę, że złączenia 7 tabel będą się wolniej wykonywały niż operacje na jednej tabeli.

+

Według mnie poczytaj sobie o postaciach normalnych i myślę, że znajdziesz to czego szukasz, bo możemy dyskutować o tym, która metoda jest lepsza, ale tak na prawdę Ty sam wiesz najlepiej jakich Ci potrzeba tabelek i do czego mają być one używane, a jak poczytasz sobie o postaciach normalnych to tam jest napisane czym charakteryzuje się dobrze stworzona baza i jak powinna być prawidłowo zaprojektowana.

To bedzie mial joina na 20 tabel.

@awakening: pomysl o dodatkowej tabeli z indeksem (jak juz mowilem) - wrzucisz tam wszystko wg czego szukasz, i pokazujesz na wynikach wyszukiwania (nie wiecej). Albo tylko do szukania, przed pokazaniem pobierzesz ID rekordow i pobierzesz je normalnie WHERE ID IN ( 1,2,3,... ).

No ale nie znam szczegolow twojej bazy wiec musisz sam to ocenic czy to bedzie mialo sens.

[muniekw]

@dr_bonzo

To bedzie mial joina na 20 tabel.

A czy w obsłudze rekordów w bazie potrzebne będą akurat złączenia tabel? Bo może nie będzie potrzeby robić złączeń i po co kombinować?

[awakening]

Do wyświetlenia pełnego opisu (czyli tak naprawdę wszystkie dane, poza takimi czysto technicznymi jak ip itp.) będą potrzebne niestety wszystkie tabele.

Zastanawia mnie tylko dlaczego wszędzie zalezane jest normalizowanie baz danych skoro join'owanie tabel jest mało wydajne ?
Ciekaw jestem jak ten problem jest rozwiązany w bardzo duzych serwisach, które obsługują miliony użytkownik, chociażby nasza-klasa...

[erix]

Zastanawia mnie tylko dlaczego wszędzie zalezane jest normalizowanie baz danych skoro join'owanie tabel jest mało wydajne ?

Gdyż nie ma problemu ze skalowalnością, etc.

Ciekaw jestem jak ten problem jest rozwiązany w bardzo duzych serwisach, które obsługują miliony użytkownik, chociażby nasza-klasa...

Replikacja oraz load-balancing. O cache nie wspomnę.

Ciekawostka: Google nie byłoby takie szybkie, gdyby nie cache w RAM-ie części (większości?) tabel. [;
Mnesia w Erlangu też podobnie robi; część tabel na HDD, część w RAM albo mieszane.

[awakening]

Dobra, sam już nie wiem co mam zrobić, serwis początkowo, do czasu gdy nie zacznie przynosić dochodów (lub nie pojawią się takie oznaki) będzie hostowany w nazwa.pl (jak nie wytrzyma to pomyśle o jakimś VPS'ie), później po zakupieniu maszyny dedykowanej mogę pomyśleć o replikacji, cache itd. Na razie muszę to uruchomić w taki sposób żeby było jak najmniejsze obciążenie, kusi mnie normalizacja, bo lubię mieć wszystko poukładane, ale boję się, że efekt będzie gorszy niż upchanie wszystkiego w 3-4 tabelach... jakieś pomysły?

Ten post edytował awakening 15.06.2009, 11:43:55

[muniekw]

Możesz na początek spróbować zrobić to jak mówisz czyli te 3-4 tabelki. Jak nie bardzo Ci będzie to śmigać to wtedy możesz spróbować przerobić bazę. Tylko pomyśl czy nie prościej pomęczyć się od razu i mieć spokój niż później w przyszłości wszystko przerabiać

Ten post edytował muniekw 15.06.2009, 11:57:08

[awakening]

Ja chętnie zrobię od razy normalizacje, ale przeraża mnie ta liczba joinów, zwłaszcza na tym "serwerze"...

może ktoś jest w stanie się wypowiedzieć na temat serwerów, nigdy nie stawiałem nic większego na tym pseudo serwerze od nazwy (active, ten po 300zł), ciekawi mnie jak długo pociągnie nim będę musiał zainwestować w coś lepszego?
na ile pozwoli mi np. taki serwer: http://www.ovh.pl/produkty/rps4.xml ? nie jest to maszyna dedykowana, ale wydaję się być mocna

[erix]

RPS-y mają współdzielone HDD po sieci, więc to może być wąskie gardło...

[awakening]

Można wykupić wersję ze zwiększonym minimalny przepływ ISCSI, do 4, albo 10mb/s