| 

.NET C# Java Javascript Exception

0
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.
12.01.2010
The_Holy_One 393 1 6
...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
Blue 12.01.2010
Den Verlauf der Änderungen in einem frei definierbaren Zeitfenster. Immer nur bezogen auf eine Person, nicht vergleichend zu anderen.
The_Holy_One 12.01.2010
2 Antworten
1
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.
12.01.2010
lunatigs 1,3k 2 8
Wieso hast du als erste Spalte in der Haarfarbentabelle einen Autoincrement Wert? Reicht als Keyset hier nicht nur die userID + TimeStamp aus ?
The_Holy_One 12.01.2010
Ja, wenn man berücksichtigt, daß es "nicht RealTime Kritischer Natur" ist, sind die timestamps auf jeden Fall unterschiedlich ... damit kannste den Autoincrement auch weglassen.
lunatigs 12.01.2010
Ein PK Sollte 1. technischer Natur und 2. nicht zusammengesetzt sein. Insofern ist die ursprüngliche Lösung, mit einem (von den Daten losgelösten) Autoincrement, die Bessere!
FalkP 13.01.2010
Gleichartige Attribute in unterschiedliche Tabellen zu speichern ist nicht unbedingt optimal. U.U. lohnt sich der Aufwand den Grips in die Verwaltung unterschiedlicher (aber ähnlicher) Attribute in EINER Tabelle zu investieren. Man erleichtert sich die Arbeit ggfs. erheblich. Das Anlegen neuer Attribute ist sonst mit einem CREATE TABLE und dem Anpassen sämtlicher Abfragen verbunden. Bei vielen Attributen bestehen die Abfragen auserdem aus entsprechend vielen OUTER JOINs, was es nicht unbedingt übersichtlicher und wartbarer macht.
FalkP 13.01.2010
0
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 :) ?
12.01.2010
The_Holy_One 393 1 6
Ok, mal abgesehen davon, daß das keine Antwort sondern eine Frage ist ... :) ...

Tabelle Char
1 | Testchar

Tabelle Leben
1 | 2000 | 1234567
1 | 2100 | 1234569

Tabelle Rüstung
1 | Hut_1 | 50 | 1234567
1 | Hut_2 | 95 | 1234568

2000 leben + 50 leben von hut_1 = 2050
2000 leben + 95 leben von hut_2 = 2095
2100 leben + 95 leben von hut_2 = 2195
lunatigs 12.01.2010

Stelle deine Sql-Frage jetzt!