Szybkosc dzialania BD

Witam! To moj pierwszy post, wiec chcialem zasiegnac porady dotyczacej szybkosci dzialania bazy danych, "obslugiwanej" przez php...oczywiscie chcialem zaczac od czegos ogolnie dostepnego i dosc taniego...zalozenie jest takie - szybka w dzialaniu baza danych dla setek tysiecy uzytkownikow...przedstawiam dwie koncepcje takiej bazy:

trzy tabele:
tabela produkt (obok ID.produkt ID.user)
tabela kategoria (ID.produkt ID.kategoria ID.user)
tabela podkategoria (ID.produkt ID.kategoria i ID.User)

czy podzielic to tak:

tabele kategorii (gdzie bedzie od razu kolumna z nadanym ID.produktu, ID.kategoria, ID.user itd)

tyle ze takich tabel bedzie tyle co kategorii...czyli sporo...mozna rzec nawet ze 100 :) chodzi głównie o szybkosc dzialania...nie wiem czy mysql lepiej sobie radzi z jedna tabela z milionem rekordow i spora liczba userow (zalozmy ze userow jest pare setek tysiecy) czy z kilkoma tabelami ktore dziela ta ilosc rekordow :) najbardziej boje sie wyszukiwarki...gdyz kazde zapytanie wertuje tabele od poczatku do konca, wiec co by sie dzialo w tabeli z wieloma rekordami gdyby kilkuset userow jednoczesnie wyszukiwalo czegos...bardzo bym prosil o pomoc....baza jest hipotetyczna...chodzi glownie o dzialanie dla ogromnej ilosci uzytkownikow

Po co w tabeli produkt, kategoria i podkategoria jest id.user? W ogóle nie napisałeś co będzie w tych tabelach, co to będzie za aplikacja. Nie jesteśmy wróżkami. Na podstawie tych informacji, które podałeś do tej pory mogę powiedzieć, że obie podane koncepcje bazy są błędne z punktu widzenia normalizacji oraz standardów projektowania baz danych.

no tak :) to ma byc wirtualny sklep :) cos jak allegro :) a user potrzebny z tego powodu ze produkty beda przypisywane do userow...sorki :) roztargnienie

Przede wszystkim brakuje tabeli userów. Po drugie id.user jest niepotrzebny w tabelach kategorii i podkategorii. Po trzecie brakuje tabel w których będzie odnotowywana sprzedaż. Po czwarte brakuje czegoś w stylu koszyka, listy zakupów.

:) wieczorem przedstawie ogolna postac tych tabel zgodnie z zalozeniami wykladowcy :) potrzebuje na zaliczenie/egzamin :) przy czym chodzi glownie o problem szybkosci dzialania...mysle ze na tym powinienem sie skupic....czyli robic duzo tabel czy ograniczac ilosc tabel....

Jeśli to tylko na zaliczenie, to problem wydajności raczej nie istnieje.

u nas glownie skupiaja sie na wydajnosci i funkcjonalnosci...generalnie ma to byc baza ktora bedzie dzialac z ogromna liczba uzytkownikow naraz...

Ale wydajności bazy danych nie można rozpatrywać w oderwaniu jej od aplikacji, która będzie jej używała. Bo projekt bazy i/lub użyte sztuczki/triki zależne są od SZBD oraz operacji jakie są na bazie wykonywane.

Z jednej strony indexy pomagają przy selectach, z drugiej ich duża liczba na tabeli spowalnia operacji modyfikacji danych. To tylko takie jeden przykład, pokazujący że nie ma uniwersalnej zasady.

Ciekawy przykład był swego czasu np. z portalem pracuj.pl, który przetwarzał dużą liczbę danych. Wstawiania nowych ofert etc., do tego stopnia że postawili jedną bazę do której wstawiane były dane, z małą liczbą (czy prawie bez) indexów. Oraz posiadali drugą bazę, gdzie dane były przenoszone w nocy, która służyła tylko do zapytań (wyszukiwań) i posiadała masę indeksów na tabelach, co przyspieszało wyszukiwania, agregację etc. Jest to przykład pewnej sztuczki, która mocna ze specyfiką ich biznesu była związana. Więc znowu widzisz że nie ma uniwersalnej zasady, np. w banku taka sztuczka nie przejdzie, bo zmianę salda musisz widzieć od razu, a nie następnego dnia.

i w końcu tak naprawdę optymalizacja ta właściwa zaczyna się jak już masz ileś tych danych testowych i jesteś w stanie przemielić parę(dziesiąt/set) zapytań i zobaczyć gdzie jakiego indeksu potrzebujesz, gdzie zamiast tabeli znormalizowanej do 3PN znacznie lepiej sprawdzi się w tzw 2,5 PN, itd, itp. Generalnie na etapie projektowania to sobie możesz powymyślać różne różności, ale i tak zweryfikuje je życie