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

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.

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

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)?

@muniekw:

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.

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)

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.

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ę?

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.

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

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ę

+



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.

@dr_bonzo
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ć?

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...

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


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.

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?

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ć

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

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

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

Ehhhh,
@awakening
zacznij od zrobienia szukarki na tym co masz, normalizacja ma ci ulatwic operowanie na rekordach, zebys np. nie musial nazwy wojewodztwa wszedzie wpisywac, tylko np wpisac jego ID itd.

Odpal sobie szukarke i listing, sprawdz wydajnosc - jak bedzie OK to zostaw. Potem na nazwie potestuj.

I jak bedzie powolne to denormalizuj baze (nie musisz calej, ale dodac dodatkowe rekordy ktore przydadza ci sie w szukarce)

z tym, że szukarka będzie głównie po kategoriach, wojewodztwach itp. czyli dane już zdefiniowane, do tego możliwość wyboru atrybutów, które też są stałe, na dobrą sprawę jedyną zmienną w wyszukiwaniu jaką będzie mógł wprowadzić użytkownik będzie miejscowosc

Jasne, dlatego napisałem żeby stworzyć widok ze względu na wygodę użytkowania. Czyli jestem za rozbiciem na X mniejszych tabel aby schemat bazy był poprawny ale żeby wygodniej było operowac na danych to stworzyłbym odpowiedni widok.

A czy jesteś w stanie udowodnić jak wiele zapytań do różnych tabel jest szybsze od jednego na dużej?
Oczywiście mile widziane potwierdzenie liczbami.

Właśnie o to chodzi, że zapytanie do wielu małych tabel nie jest szybsze od jednego do dużej tabeli

Wiec nie ma o czym mówić. Nie widzę jakiejś naprawdę ogromnej zalety dzielenia dużej tabeli.

to, że się dane nie dublują, nie tworzą się anomalie i nie robią się dziury w bazie, a zmiana wartości jednego atrybutu nie wymaga uaktualnienia wszystkich rekordów, to dla Ciebie nie jest ogromna zaleta?!

Eh, kurde. Albo masz idealnie znormalizowana baze z ktorej twoj prof. na uczelni bedzie zadowolony albo masz szybki skrypt. wybieraj.

teraz to mam jeden wielki burdel w bazie i w kodzie, nie mogę zrobić wszystkiego na jednej tabeli i muszę teraz walczyć z dziwnymi zapytaniami, na pewno nie da się pobrać wszystkich danych jednym zapytaniem, wydaje mi się, że będą to 3 lub 4, przy pobieraniu danych z poprawnie zbudowanej tablicy relatywnej da się wszystko pobrac jednym zapytaniem?

Pokaż może strukturę aktualnej bazy jaką masz (najlepiej w formie grafu czy podobnych dobrodziejstw) to my ci pokażemy na przykładzie paru tabel jak ładnie je zorganizować.