Design einer Statistik-Datenbank

C167

Nabend, ich versuche mich juxweise an einer Statistikdatenbank.
Geschpeichert werden sollen Daten ueber "Teams", jeweils ueber 30 (31) Tage.
Dabei enthaellt jedes Team einige statische Daten (Name, Beschreibung, ID) die in eine extra-Tabelle wandern, sowie auch die eigentlichen Statistikdaten. Um genau die geht es mir. Notwendig waere wohl eine RoundRobin-Database (wie es das RRDtool vormacht). Nur wie speichere ich die Daten ab? eine Tabelle fuer jeden Tag (also 30 stueck)? Dann in eine Optionentabelle die aktuelle Nummer die als letztes upgedated wurde um mit nem Tool beim updaten automatisch die naechste zu waehlen? Was ist der Beste Ansatz? die DB kann durchaus insgesamt ueber 30GB(!!!) gross werden, das Konzept sollte also performant und gut durchdacht sein... Ich dachte anfangs nicht dass ich auf solche Probleme stossen werde, bisher bin ich mit Datenbanken (MySQL) recht gut zurechtgekommen.

C167

Moin,
erstelle doch erstmal eine Tabelle mit allen Daten die du sammeln willst und dann
normaliesire diese oder erstell wahlweise erstmal ein ER-Diagramm. Und schreib dir am besten vorher so eine Art von Pflichtenheft.

MFG

C167

Franck schrieb:

Moin,
erstelle doch erstmal eine Tabelle mit allen Daten die du sammeln willst

okay, das ist recht schnell erledigt...

Franck schrieb:

und dann
normaliesire diese

normalisieren? das kenne ich nur aus IT Hardware: Disjunktive Normalform

Franck schrieb:

oder erstell wahlweise erstmal ein ER-Diagramm.

unbekannt, muss ich mich einlesen, sobald die arbeiten in der Schule rum sind

Franck schrieb:

Und schreib dir am besten vorher so eine Art von Pflichtenheft.
MFG

Okay, thx soweit... hab heut noch nen Satz arbeiten reingeknallt bekommen, darum wird das sich etwas ziehen
C167

€dit: ER = http://de.wikipedia.org/wiki/Entity-Relationship-Modell ? dann geht das, sowas haben wir in einfacherer Form schonmal gemacht...

CarstenJ

Hi,

im Endeffekt sähe das dann so aus (2 Tabellen) und ist auch nicht so schwierig:

id | Team | Beschreibung |
---------------------------
 1 | Blau | Blaues Team  |
 2 | Rot  | Rotes Team   |

id | foreignKey | Tag        | Wert |
--------------------------------------
1  |           1|  01.01.2008| 3000 |     
2  |           2|  02.01.2008| 2800 |
3  |           1|  03.01.2008| 2300 | 

# Am 01.01.2008 hatte das Blaue Team (fk = 1) einen Wert von 3000.
# Am 02.01.2008 hatte das Rote Team (fk = 2) einen Wert von 2800. 
# Am 03.01.2008 hatte das Blaue Team (fk = 1) einen Wert von 2300.

Durch geschickte SQL Abfragen bekommt man also für jeden Tag den Wert eines bestimmten Teams heraus, und kann damit natürlich auch den Durchschnitt, Min und Max Wert bestimmen.

Das ist doch im Grunde, was du brauchst, oder?

C167

ja schon, nur dass ich dabei alles in einer Tabelle habe, und ich da mehrere GB an Daten haben werde... und da is es mir dann doch schon wichtig dass die DB da net so viel Arbeit hat die Daten aus einer Mamut-Tabelle zu ziehen...

CarstenJ

Hallo,

das hängt davon ab, wie viele verschiedene Werte da tatsächlich drinstehen und wie die Abfrage aussieht. Je nach Anwedungsfall, können Indizes sehr viel Zeit sparen:
http://de.wikipedia.org/wiki/Datenbankindex
http://dev.mysql.com/doc/refman/5.1/de/mysql-indexes.html

Nur weil es mehrere GB an Daten sind, muss die DB nicht zwangsläufig langsam sein. Wobei natürlich auch Faktoren wie Festplattengeschwindigkeit und Rechnerleistung ausschlagebend sein können. Selbst bei der Installation kann man, je nach DB, schon einiges an Performance verschenken bzw. gewinnen, je nach Anwedungsfall.

Unix-Tom

Du kannst natürlich für jedes Monat eine Tabelle anlegen. Kommt aber immer auf den Anwendungsfall an. Je größer eine Tabelle bei MySQL wird umso langsamer ist sie.
Mehrere Tabellen haben den Vorteil dass sie sich nicht Gegenseitig sperren wenn es auch viele INSERTS gibt.
Du solltest Dir also vorher klar darüber sein was Du machen willst, wieviele Client darauf GLEICHZEITIG zugreifen, wieviele schreiben, wieviele UPDATES es geben kann, etc.
Anlegen eine Tabelle darf dann natürlich nur einer.

Wenn Du wirklich mehrere GB an Daten hast wird es schnell zum Problem wenn es nur ein Monat betrifft.
Kommen diese Mengen aber durch die Jahre kann man dann Daten auslagern und extra bereit stellen.