Witam.
Mam pytanie odnośnie wydajności:
Co lepsze?
tabelka_numerproduktu = 20 000 * ilość lat (po 10 latach mamy 200 000)
czy
tabelka_numerproduktu_rok = 20 000; (bez względu na ilość lat 20 000)

Wszystko jest oczywiste że tabele z podziałem na rok mają większy sens ale..

Mamy powiedzmy 3000 produktów to nam daje = 3 000 * 10 = 30 000 tabel

Jak mysql radzi sobie z taką ilością tabel i czy nie lepiej upchać te 200 000tys w jedną tabelkę?
Baza mysql będzie cały czas pobierać dane (duże ciężkie zapytania) i cały czas dodawać nowe (20 000 x 3000 / 365 = 114 na minute)

Pozdrawiam i mam nadzieje że jakiś znawca mysql się wypowie.

PS: Co jeśli produkt wypali i zamiast 3 000 będzie 30 000?

Nic z tego opisu nie zrozumiałem prócz tego, że zamierzasz zakładak x dziesiąt tysięcy tabel dla produktu. WHY? Co masz takiego w tym produkcie, że musisz zakładać tyle tabel dla niego?

To nie produkt a id usługi dla klienta.
Chodzi oto że nie chce wsadzić wszystkich danych do jednej tabelki (jest już takie rozwiązanie i po 7 latach mamy tabelki po 10 milionów rekordów w ciągu pół roku(bo tyle jesteśmy wstanie przechować potem stare dane są kasowane)
Zależy mi na odpowiedzi czy lepiej 3000 (albo 30 000) tabel po 200 000tys.(10 lat) i z każdym rokiem coraz gorzej + liczymy że w ciągu roku będzie tylko 20 000 rekordów a będzie więcej.
Czy 3000(albo 30 000)*10(lat) tabel po 20 000tys(albo więcej) rekordów
To strasznie dużo tabel. Problem jest w tym że muszę być przygotowany na dużą ilość danych i nie chce przykrości że coś źle zostało zaprojektowane.
Jak mysql radzi sobie z przechowywaniem tak dużej ilości tabel i otwieraniem za każdym razem innej.?
PS: Aktualnie dane i tak są rozdzielane na 10 tabel po 10milionów rekordów .. i przechowują dane z pół roku ! Gdzie tu zaprojektować system na historie sprzed 10 lat w takich warunkach.
Dlatego muszę to podzielić na tabele tylko czy mysql nie będzie miał problemów z tak dużą ilością.

Dziwne podejście... Jeśli baza ma odpowiednio zbudowaną strukturę to nie ma potrzeby rozdzielać danych pomiędzy takie pseudo-optymalne rozwiązania. Napisz konkretnie jakie dane musisz przechowywać, w jaki sposób chciałeś sam to zbudować wtedy będziemy mogli spróbować cokolwiek konkretnego Ci doradzić.

Pozdrawiam

Jest urządzenie które monitoruje stan innego urządzenia i cały czas wysyła pakiety do systemu.
(różne pakiety z rożnych czujników np temperatura, stan, ilość przetworzonych danych,konfiguracja w hex - naprawdę różne dane.)
Widzę to tak.
stworzenie tabelek urzadzenie_id_rok == urzadzenie_123_2011;
I tam wklejać wszystkie dane.
Najważniejsze w tym wszystkim są raporty na temat danego urządzenia.
Według tego co jest aktualnie w ciągu pół roku tworzy się 10 * 10milionów rekordów. i nie tworzę z tego sensownego raportu który operuje na rożnych wartościach w where. (data, czas, int,float) i rożnych tabelkach.
Dlatego zależy mi na tym by to podzielić.
Jeden klient ma jedno ID (jedno urządzenie) więc skrypt analizował by małą porcję danych. jedną swoją tabelkę. a nie tabele która posiada dane wszystkich ID.
Operujecie na tabelkach które mają 100 milionów rekordów w ciągu pół roku? Jak ta tabelka wygląda po 5 latach..
Zdaje mi się że lepiej to chyba podzielić...

Nie wiem jak w MySQL (musiałbyś poszukać), ale w PostgreSQL jest partycjonowanie tabel. Wydaje mi się, że jest to coś, co mogłoby Ci się przydać. Widzę, że w MySQL też chyba jest to dostępne, ale nie wgłębiałem się: http://dev.mysql.com/doc/refman/5.1/en/partitioning.html

W przypadku tak dużej ilości danych postgresql sprawdzi się lepiej od mysql-a?

Od kilku lat pracuję w zdecydowanej większości na PostgreSQL więc nie powiem Ci jak się ma aktualnie do MySQL. Dane z przedziału 60mln - 110mln w 3 głównym tabelach i rozmiar bazy grubo ponad 50GB nie stanowią tu jakiegoś większego problemu.