W mojej bazie mysql dla każdego użytkownika będzie tworzona oddzielna tabela z
informacjami o jego poczynaniach w serwisie ! lub inna wersja ! - wszyscy ci
użytkownicy będą w jednej bazie i tylko na podstawie odpowiedniego filtrowania
będzie można wyciągnąć z niej informacje dotyczące określonego użytkownika. Moja wątpliwść to: czy taka duża tabela oraz wielość rekordów który powstanie w drugim przypadku oraz późniejsze filtrowanie i korzystanie z niej nie oznacza znacznego wydłużenia czasu przetwarzania strony. Który sposób jest częściej stosowany jakie są za i przeciw ?

No wiec:

To strasznie głupi pomysł, aby do każdego usera była odzielna tabelka. W tej chwili niepotrzebna by była baza danych MySQL. Wszyscy userzy w jednej bazie - to rozwiązanie każdej stronki.

Zdecydowanie 1 tabela. Jaki bedziesz mial miesieczny przyrost rekordow?

w moich przewidywaniach tabela taka będzie dość mocą wykorzystywana i docelowo może nawet osiągnąć od 500 tyś do 1 miliona rekordów - i z tego właśnie powodu obawiam się dużych opóźnień w przetwarzaniu strony.

Max 1 milion to dla MySQL nie jest jeszcze tak duzo. Jak dobrze dostroisz zapytania to czasy beda zadowalajace.

Sorry ale do mojego zapytania wkradł się mały błąd, który i tak nie ma już tu specjalnego znaczenia ale dla ścisłowść załączam poprawioną wersję:

W mojej bazie mysql dla każdego użytkownika będzie tworzona oddzielna tabela z
informacjami o jego poczynaniach w serwisie ! lub inna wersja ! - wszyscy ci
użytkownicy będą w jednej tabeli [ było błędnie: bazie ] i tylko na podstawie odpowiedniego filtrowania będzie można wyciągnąć z niej informacje dotyczące określonego użytkownika. Moja wątpliwść to: czy taka duża tabela oraz wielość rekordów który powstanie w drugim przypadku oraz późniejsze filtrowanie i korzystanie z niej nie oznacza znacznego wydłużenia czasu przetwarzania strony. Który sposób jest częściej stosowany jakie są za i przeciw ?

Moja propozycja to dwie tabelki. W pierwszej userzy, nazwa imie nazwisko adres, mail,, telefon, www itd ID to ostatnie bardzo ważne!!! I druga tabelka z wszystkimi danmi do konkretnego usera. Potem stwórz relację!!! Przecież MySQL to relacyjna baza danych i po to są w niej relacje. Jeżeli dane jaki zbierasz o userze (te 1000000 rekordów) są bardzo zróźnicowane, to będziesz musiał je pogrupować i potworzyć tabele do każdego rodzaju danych. Ale nie wierze że masz milion rodzajów danych. Dlatego dobrze przymyśl sprawę i weź pod uwagę (i nic inengo) relacje pomiędzy tabelkami.

Przepraszam, że się wtrącam, ale robię teraz pewien system. MySQL +php. W bazie mam kilka przykładowych próbek danych, zapytania dopieszczone - tak żęby jak najmniej obciążać bazę. Jak pobiram jakieś dane to słyszę jak mieli dyskiem (jakbym pobierał conajmniej 20000 rekordów). Zastanawiam się czy to mielenie jest normalne?

Pozdrawiam

Ważny jest czas zwrócenia zapytania. Sprawdź z poziomu MyPhpAdmin lub konsoli jaki jest czas zwrotu zapytania (podany w milisekundach). A jak Ci dysk mieli za głośno to albo defragmentuj dysk albo go wymień, ale to temat na inne forum.

@J4r0d

Normalne to nie jest. Moze masz pliki porozrzucane po calym hdd, jesli masz duzy czas - wystarczy dostroic SQLa, lub pomyslec o przebudowanie bazy wtedy czasy dzialania Ci spadna jak i wykorzystanie mocy procka.

@jajacek Troche niezbyt dobrym sposobem jest stosowanie wielu tabel, powod jest jeden bardzo wazny - trudno sie wtedy skomplikowane zapytania definiuje. A kazdy wie ze UNION jest bardzo wolny.

Prawda.
Gdzieś czytałem że MySQL tworzy tempa dla takich zapytań a PostgreSQL posługuje się referencjami.
Ale mogę się mylić

Chodzilo mi o sam algorytm sumowania.

Mysle ze dla INNO DB (MySQL) dzialanie jest dokladnie takie samo jak dla Postgresa.

Odświeżam temat bo problem znowu występuje. Mam nowy dysk, dopiero co defragmentowany. I przy pobieraniu danych z bazy słyszę jak mieli. Czasy odpowiedzi wahają się róznie ale nie są niby duże. Może dlatgo, że to na localhost ?