Hi Leute,
Ich möchte gerne eine Datenbank erstellen mit dennen im Anschluss über eine WebSeite (PHP) Statistiken generieren lasse. Dementsprechend müssen die Daten die ich für die Statistik benötige in der SQL Datenbank vorhanden sein, nur wie speichert man diese möglichst effizient in dieser ab?
Ein kleines Beispiel anhand einer Personenentwicklung:
Eine Person hat: Ein Alter, eine größe, ggf. (bekannte) Fähigkeiten (z.b: in Form von Noten in Fächern, oder Schulungen), eine Adresse, Geschlecht, Besitz, usw.
Wenn ich jetzt von x-Personen nachverfolgen möchte wie diese sich im laufe der 'Zeit' weiterentwickeln müsste die Datenbank, zumindest in meinem Laeinhaften wissen, wie folgt aussehen:
//Table: Users - Attribute die sich niemals ändern
// Angenommen der Name & Adresse des Users ändert sich niemals!
{userid (pkey)} {name} {adresse} {herkunftsland} {geschlecht}
//Table: User_Informationen - Attribute die sich ändern.
{userid (foreign key)} {Informationszeitpunkt (pkey)} {auto} {haus} {vereinsmitgliedschaften} {photo} {titel} {alter} {persönliches statement}
Wie man unschwer erkennen kann soll die Relation zu der DB wie folgt aussehen. Es gibt mehrere User_Informationen (0...n) jedoch immer genau einen User dem diese zugeordnet werden (1). Hierfür ist es aber notwendig, das in der Tabelle User_Informationen eine Art "Zeitpunkt" mitspeichert, weshalb der zusätzliche Primary Key "Informationszeitpunkt" von nöten wird.
So weit so gut, bis dahin bin ich, wie man ja unswer erkennen kann, selbst gekommen. Nur habe ich niemanden der mir sagen kann ob dies von der "Denkweise" so auch richtig ist. Um redundante Daten zu verhindern würde ich vor dem schreiben in die Datenbank zuvor den letzten Informationsdatensatz abrufen und mit den neu zu schreibenden Daten vergleichen, falls diese sich nicht unterscheiden, wird einfach nichts neu gespeichert.
Der Schreibcyclus wäre momentan ca. 1x Stündlich, also nicht RealTime Kritischer Natur. Vielmehr geht es hierbei wirklich um die maximale effizienz & Datengröße.
Ich möchte gerne eine Datenbank erstellen mit dennen im Anschluss über eine WebSeite (PHP) Statistiken generieren lasse. Dementsprechend müssen die Daten die ich für die Statistik benötige in der SQL Datenbank vorhanden sein, nur wie speichert man diese möglichst effizient in dieser ab?
Ein kleines Beispiel anhand einer Personenentwicklung:
Eine Person hat: Ein Alter, eine größe, ggf. (bekannte) Fähigkeiten (z.b: in Form von Noten in Fächern, oder Schulungen), eine Adresse, Geschlecht, Besitz, usw.
Wenn ich jetzt von x-Personen nachverfolgen möchte wie diese sich im laufe der 'Zeit' weiterentwickeln müsste die Datenbank, zumindest in meinem Laeinhaften wissen, wie folgt aussehen:
//Table: Users - Attribute die sich niemals ändern
// Angenommen der Name & Adresse des Users ändert sich niemals!
{userid (pkey)} {name} {adresse} {herkunftsland} {geschlecht}
//Table: User_Informationen - Attribute die sich ändern.
{userid (foreign key)} {Informationszeitpunkt (pkey)} {auto} {haus} {vereinsmitgliedschaften} {photo} {titel} {alter} {persönliches statement}
Wie man unschwer erkennen kann soll die Relation zu der DB wie folgt aussehen. Es gibt mehrere User_Informationen (0...n) jedoch immer genau einen User dem diese zugeordnet werden (1). Hierfür ist es aber notwendig, das in der Tabelle User_Informationen eine Art "Zeitpunkt" mitspeichert, weshalb der zusätzliche Primary Key "Informationszeitpunkt" von nöten wird.
So weit so gut, bis dahin bin ich, wie man ja unswer erkennen kann, selbst gekommen. Nur habe ich niemanden der mir sagen kann ob dies von der "Denkweise" so auch richtig ist. Um redundante Daten zu verhindern würde ich vor dem schreiben in die Datenbank zuvor den letzten Informationsdatensatz abrufen und mit den neu zu schreibenden Daten vergleichen, falls diese sich nicht unterscheiden, wird einfach nichts neu gespeichert.
Der Schreibcyclus wäre momentan ca. 1x Stündlich, also nicht RealTime Kritischer Natur. Vielmehr geht es hierbei wirklich um die maximale effizienz & Datengröße.
|
373 ● 5 |
|
...eine Statistik-Datenbank! Soweit sogut. Was willst du anzeigen? ...den Verlauf der Änderungen oder eine Statistik zu mehreren Personen untereinander? z.B. Wieviel Leute sind weiblich? ...unter 18 Jahre usw. oder eher wieoft ist EINE Person umgezogen ;-) Grüßle
|
||
|
Den Verlauf der Änderungen in einem frei definierbaren Zeitfenster. Immer nur bezogen auf eine Person, nicht vergleichend zu anderen.
|
2 Antworten
Als allgemeiner Gedanke dazu:
Wenn Du sowieso eine Tabelle mit Daten hast, die sich nie ändern, sprich: Du immer eine eindeutige Zuordnung zum jeweiligen User vornehmen kannst, dann klingt für mich folgendes effizient:
Für jede Eigenschaft machst Du eine eigene Tabelle und verknüpfst die jeweiligen Daten über die Primary Keys mit dem entsprechenden User.
Ist jetzt eine aktuelle Eigenschaft anders, als die zuletzt gespeicherte, wird die aktuelle neu in die Tabelle eingefügt (inkl. aktuellem timestamp).
Somit hast Du dann irgendwann einen Grund-Datensatz für den User und in den ganzen Eigenschaften-Tabellen n*n Eigenschaften zu diesem User.
Beim Auslesen brauchst Du jetzt nur noch die Eigenschaften zu dem User sortiert anhand der timestamps holen und hast automatisch zu allen Eigenschaft einen chronologischen Verlauf.
Mal grob dargestellt:
User-Tabelle:
1 | Tony | Test
Tabelle Haarfarbe:
1 | 1 | Blond | 1234567
2 | 1 | Braun | 1234568
Damit wäre klar, das Tony Test zuerst blond war und dann braune Haare hatte.
Wenn Du sowieso eine Tabelle mit Daten hast, die sich nie ändern, sprich: Du immer eine eindeutige Zuordnung zum jeweiligen User vornehmen kannst, dann klingt für mich folgendes effizient:
Für jede Eigenschaft machst Du eine eigene Tabelle und verknüpfst die jeweiligen Daten über die Primary Keys mit dem entsprechenden User.
Ist jetzt eine aktuelle Eigenschaft anders, als die zuletzt gespeicherte, wird die aktuelle neu in die Tabelle eingefügt (inkl. aktuellem timestamp).
Somit hast Du dann irgendwann einen Grund-Datensatz für den User und in den ganzen Eigenschaften-Tabellen n*n Eigenschaften zu diesem User.
Beim Auslesen brauchst Du jetzt nur noch die Eigenschaften zu dem User sortiert anhand der timestamps holen und hast automatisch zu allen Eigenschaft einen chronologischen Verlauf.
Mal grob dargestellt:
User-Tabelle:
1 | Tony | Test
Tabelle Haarfarbe:
1 | 1 | Blond | 1234567
2 | 1 | Braun | 1234568
Damit wäre klar, das Tony Test zuerst blond war und dann braune Haare hatte.
|
852 ● 1 ● 4 |
Nur um 100% auf nr. sicher zu gehen.
Daten die sich "gleichzeitig" ändern kommen alle in die ein und die selbe Tabelle. Daten die sich unabhängig von anderen Werten verändern bekommen eine eigene, so wie von dir (lunatigs) beschrieben?
Hmm, anhand eines Beispiel's bei MMORPG's wohl am besten erklärt. Wenn ein Character (dessen Name sich ja nicht ändert), im Level aufsteigt, so ändert sich zwangsläufig die HP/MP ect. ja auch von dem Character. Würde man dies auf diesen Umstand beschränken wäre es kein Problem HP/MP ect. in eine "gemeinschaftstabelle" zu stecken. Also in einer in dennen sich die Attributte immer gemeinsam ändern.
Fügt man diesem Szenario aber wieder hinzu das ein Spieler ja auch aufgrund seiner Ausrüstung spezifische Werte direkt manipulieren kann, und geht man weiter davon aus das alle Attribute einzeln geändert werden können (z.b.: eine gruppierung nicht offensichtlich ist). So müsste jeder Wert wieder eine eigene Tabelle erhalten (mit userid & timestamp)
Sehe ich das richtig so :) ?
Daten die sich "gleichzeitig" ändern kommen alle in die ein und die selbe Tabelle. Daten die sich unabhängig von anderen Werten verändern bekommen eine eigene, so wie von dir (lunatigs) beschrieben?
Hmm, anhand eines Beispiel's bei MMORPG's wohl am besten erklärt. Wenn ein Character (dessen Name sich ja nicht ändert), im Level aufsteigt, so ändert sich zwangsläufig die HP/MP ect. ja auch von dem Character. Würde man dies auf diesen Umstand beschränken wäre es kein Problem HP/MP ect. in eine "gemeinschaftstabelle" zu stecken. Also in einer in dennen sich die Attributte immer gemeinsam ändern.
Fügt man diesem Szenario aber wieder hinzu das ein Spieler ja auch aufgrund seiner Ausrüstung spezifische Werte direkt manipulieren kann, und geht man weiter davon aus das alle Attribute einzeln geändert werden können (z.b.: eine gruppierung nicht offensichtlich ist). So müsste jeder Wert wieder eine eigene Tabelle erhalten (mit userid & timestamp)
Sehe ich das richtig so :) ?
|
|
373 ● 5 |
