Mehrere Ebenen speichern - Konzept

[Carl]

Hallo

ich suche jetzt schon seit mehreren Tagen nach einer Umsetztung für mein Problem, bin aber bisher noch auf nichts gekommen, dass mich zufrieden gestellt hätte.

Das Problem:

Ich habe eine sehr große Tabelle mit 102400 Feldern. Diesen Feldern ist eine bestimmte Farbe zugeordnet.

Meine Idee:

Da eine Ausgabe dieser Tabelle im Ganzen ziemlich "sinnfrei" wäre, hatte ich die Idee, das ganze in Ebenen einzuteilen. D.h. ich möchte das Ganze als eine grafische Repräsentation in Tabellenform ausgeben, wobei die Tabelle mit maximal 20x20 Feldern angezeigt werden soll. Dabei werden, um zur nächst höheren Ebene zu kommen immer 4 Felder zusammengefasst. Genauer: Wenn ich mich  in der untersten Ebene mit 102400 Feldern befinde und in die nächst höhere  aufsteige, werden die Felder 1, 2, 51201, 51202 zu einem Feld zusammengefasst welches dann so zu sagen wieder zu Feld 1 wird. Wenn man nun von der obersten Ebene in die nächsttiefere Ebene in der Anzeige springt, wird nicht die ganze Ebene mit 1600 Felder angezeigt, sondern wieder nur eine 20x20 Felder große Tabelle.

Das Problem:

Die Umsetzung. Ich hatte mir schon überlegt, für jede Ebene eine Tabelle zu erstellen, aber ich weiß nicht, wie ich dann die Tabellen miteinander Verknüpfen soll.

Ich hoffe jemand von euch hat einen oder mehrere Ansätze für mich.

Gruß
Carl

[Vinzenz Mai]

Hallo Carl,

vielleicht hast Du Dich gewundert, dass Du verhältnismäßig lange auf ein Antwortposting warten musstest. Die Ursache dafür liegt meiner Meinung nach leider bei Deinem Ausgangsposting :-(
Ich denke, Du hast den falschen Themenbereich gewählt und Dein Problem nicht hinreichend beschrieben. Ich versuche Dir so gut zu helfen, wie ich kann.

Das Problem:

Ich habe eine sehr große Tabelle mit 102400 Feldern. Diesen Feldern ist eine bestimmte Farbe zugeordnet.

hier beginnt _mein_ Problem mit Deiner Erklärung:

Du postest unter dem Themenbereich Datenbanken. In diesem Bereich bin ich wahrscheinlich betriebsblind und Scheuklappenträger. Bei Datenbanken denke ich an Datenbankmanagementsysteme (DBMS), zumeist an relationale DBMS, und die von diesen verwalteten Datenbanken. Deine "Tabelle" scheint mir keine Tabelle einer solchen Datenbank zu sein, sondern etwas anderes.

Bitte bedenke, dass in dem von mir angesprochenen Umfeld "Feld" synonym mit "Spalte" oder "Attribut" gebraucht wird. Eine Tabelle mit 102400 Spalten ist extrem unhandlich und dürfte die Grenze der Datensatzgröße wohl aller üblichen DBMS sprengen :-) Daher gehe ich davon aus, dass Deine "Tabelle" keine Datenbanktabelle in diesem Sinne ist, sondern etwas anderes.

Meine Idee:

Da eine Ausgabe dieser Tabelle im Ganzen ziemlich "sinnfrei" wäre, hatte ich die Idee, das ganze in Ebenen einzuteilen. D.h. ich möchte das Ganze als eine grafische Repräsentation in Tabellenform ausgeben, wobei die Tabelle mit maximal 20x20 Feldern angezeigt werden soll.

Ah ja, wir kommen der Sache näher. Du sprichst auf einmal von 20x20 "Feldern"; ich vermute daher, dass Deine "Tabelle" schlicht und einfach ein zweidimensionales Gebilde ist, das Du in Zeilen und Spalten einteilen kannst. Jeden Wert, der durch eine Zeilen- und Spaltennummer eindeutig bestimmt ist, nennst Du "Feld", vergleichbar zu den Feldern eines Schachbretts. Trifft diese Vermutung zu? Solch ein Gebilde kannst Du übrigens Matrix nennen, für die Verarbeitung solcher Daten bieten sich Arrays an. In dem von mir verlinkten Wikipediaartikel ist von einer zweidimensionalen Anordnung in Tabellenform die Rede; bitte beachte dass eine solche Tabelle mit einer Tabelle meiner geliebten Datenbanken wenig gemeinsam hat.

Wenn meine Vermutung zutrifft, dann vermute ich aus Deinen Angaben, dass Du ein Raster mit 320 Zeilen und 320 Spalten hast, die Darstellung des Gebildes mit genau einem Pixel pro "Feld" wäre somit ein Quadrat mit 320 Pixel Kantenlänge. Ich sehe in dieser Darstellung kein Problem. Wenn es eines wäre, so wären weitere Informationen sehr hilfreich.

Dabei werden, um zur nächst höheren Ebene zu kommen immer 4 Felder zusammengefasst. Genauer: Wenn ich mich  in der untersten Ebene mit 102400 Feldern befinde und in die nächst höhere  aufsteige, werden die Felder 1, 2, 51201, 51202

Warum ausgerechnet diese? Und wie zählst Du durch? Dies dürfte eine Kernfrage Deines Problemes sein.

zu einem Feld zusammengefasst welches dann so zu sagen wieder zu Feld 1 wird. Wenn man nun von der obersten Ebene in die nächsttiefere Ebene in der Anzeige springt, wird nicht die ganze Ebene mit 1600 Felder angezeigt, sondern wieder nur eine 20x20 Felder große Tabelle.

Das Problem:

Die Umsetzung. Ich hatte mir schon überlegt, für jede Ebene eine Tabelle zu erstellen, aber ich weiß nicht, wie ich dann die Tabellen miteinander Verknüpfen soll.

Wenn Du diese Werte wirklich in einer Datenbank im oben von mir angesprochenen Sinne abspeichern willst, so bietet sich eine Tabelle mit drei Spalten an:

1. x-Koordinate (Spalte)
2. y-Koordinate (Zeile)
3. Farbwert

Als Primärschlüssel könntest Du entweder ein weitere Spalte verwenden oder auch den kombinierten Index über die ersten beiden von mir genannten Spalten. Da Dein Gebilde seine Größe nicht ändert hast Du eine Tabelle mit 102400 Datensätzen. Dies stellt für ein normales DBMS überhaupt kein Problem dar.

Wenn Du für die Ausgabe mehrere Deiner "Felder" zusammenfassen willst, so benötigst Du nur eine entsprechende Vorschrift, z.B. vier im Quadrat nebeneinander liegende Punkte bzw. warum nicht gleich ein Quadrat mit einer Kantenlänge von 16 ("Feldern"). Es sollte möglich sein, mit einer cleveren SQL-Anweisung Deine 102400 Datensätze auf die von Dir gewünschten 400 Datensätze zu reduzieren (z.B. mit einem Mittelwert). Alternativ könntest Du dies auch in der API (d.h. Deinem Skript, dass auf diese Daten zugreift) tun.

Andererseits könntest Du die Daten ganz normal in einer Datei speichern, z.B. in einem Bildformat. Dann hast Du überhaupt kein Problem mit der Ausgabe, Du gibst einfach das Bild aus. Bei einer Datenänderung änderst Du den Farbwert am entsprechenden Punkt. Dazu greifst Du mit der Programmiersprache Deiner Wahl auf die entsprechende Funktion der Dir zur Verfügung stehenden Grafikbibliothek zu. Wenn Du noch nicht weißt, wie das geht, dann frage einfach nach. Wir helfen in einem solchen Fall gerne.

Ich hoffe jemand von euch hat einen oder mehrere Ansätze für mich.

Du solltest zunächst folgende Fragen klären:

1. Die Speicherung Deiner Daten, daraus resultiert der Zugriff auf die Daten.
2. In welcher Form möchtest Du Deine Daten ausgeben.
3. Welche Verarbeitung der gespeicherten Daten ist dazu erforderlich.

das klassische EVA-Prinzip. Die Speicherung Deiner "Ebenen" sollte nicht erforderlich sein, denn diese Information ergibt sich ja aus Deinen Rohdaten. Je nach Zugriff könnte es aus Performancegründen sinnvoll sein, diese "Ebenen" zwischenzuspeichern. Dazu wären mehr Informationen notwendig, was Du mit diesen Daten vorhast, wie oft diese sich ändern, wie oft diese Daten gelesen werden ...

Damit wir Dir besser und zielgerichteter helfen können, solltest Du Informationen nachlegen und vielleicht einen angemessenen Themenbereich wählen. Ich kann mir durchaus vorstellen, dass etliche Stammposter hier den Themenbereich "Datenbanken" ausblenden.

Freundliche Grüße

Vinzenz

[Ilja]

yo,

Ich denke, Du hast den falschen Themenbereich gewählt und Dein Problem nicht hinreichend beschrieben. Ich versuche Dir so gut zu helfen, wie ich kann.

jau, als ich den beitrag lass, hatte ich auch so meine schwierigkeiten. aber ich denke, es geht denoch um tabellen von datenbanken. werde aber einfach noch mal seine antwort auf deinen posting abwarten.

Bitte bedenke, dass in dem von mir angesprochenen Umfeld "Feld" synonym mit "Spalte" oder "Attribut" gebraucht wird. Eine Tabelle mit 102400 Spalten ist extrem unhandlich und dürfte die Grenze der Datensatzgröße wohl aller üblichen DBMS sprengen :-)

was datenbanken betrifft, so sind felder keine spalten, sondern eben ein einzelnes "Tabellenfeld" mit einem inhalt. eine bestimmte spalte eines datensatzes wäre ein Feld, aber nicht die gesamte spalte. insofern hat er nicht 102400 spalten, sondern es könnte solche eine matrix sein: 10 spalten x 10240 datensätze.

Ilja

[Frank (no reg)]

Hi,

es könnten aber auch
-   1024 Spalten x  100 Datensätze oder
-    100 Spalten x 1024 Datensätze oder
-     50 Spalten x 2048 Datensätze
sein

Ciao, Frank

[Carl]

Hallo

vielleicht hast Du Dich gewundert, dass Du verhältnismäßig lange auf ein Antwortposting warten musstest. Die Ursache dafür liegt meiner Meinung nach leider bei Deinem Ausgangsposting :-(

Ja, das hatte ich schon befürchtet.

Du postest unter dem Themenbereich Datenbanken. In diesem Bereich bin ich wahrscheinlich betriebsblind und Scheuklappenträger. Bei Datenbanken denke ich an Datenbankmanagementsysteme (DBMS), zumeist an relationale DBMS, und die von diesen verwalteten Datenbanken. Deine "Tabelle" scheint mir keine Tabelle einer solchen Datenbank zu sein, sondern etwas anderes.

Der Grund, wieso ich als Themenbereich Datenbanken gewählt habe ist, dass ich den Kern des Problems in der Speicherung der Daten in der Datenbank sehe. Aber zunächst erkläre ich wohl besser, worum es mir genauer geht:

Mir war langweilig (Semesterferien fangen an ;-) ), ich hatte schon lange nicht mehr großartig programmiert und habe mich auf die Suche nach einer Herausforderung gemacht. Diese sollte nun eine Art Spiel sein. Da nur für den lokalen Einsatz bestimmt, muss ich nicht unbedingt auf die Performance achten, aber die Ausgabe von über 100000 Datensätzen in Form einer Tabelle (das "Spielfeld") würde dann doch meine Geduld etwas zu sehr strapazieren.
Ausserdem möchte ich das ganze dann auch so performant wie möglich haben. Man will ja immer nur das beste für sich.

Bitte bedenke, dass in dem von mir angesprochenen Umfeld "Feld" synonym mit "Spalte" oder "Attribut" gebraucht wird. Eine Tabelle mit 102400 Spalten ist extrem unhandlich und dürfte die Grenze der Datensatzgröße wohl aller üblichen DBMS sprengen :-) Daher gehe ich davon aus, dass Deine "Tabelle" keine Datenbanktabelle in diesem Sinne ist, sondern etwas anderes.

Es ist beides. Eine Datenbanktabelle zur Speicherung der Daten eines jeden Feldes einer zweidimensionalen Tabelle.

Ah ja, wir kommen der Sache näher. Du sprichst auf einmal von 20x20 "Feldern"; ich vermute daher, dass Deine "Tabelle" schlicht und einfach ein zweidimensionales Gebilde ist, das Du in Zeilen und Spalten einteilen kannst. Jeden Wert, der durch eine Zeilen- und Spaltennummer eindeutig bestimmt ist, nennst Du "Feld", vergleichbar zu den Feldern eines Schachbretts. Trifft diese Vermutung zu? Solch ein Gebilde kannst Du übrigens Matrix nennen, für die Verarbeitung solcher Daten bieten sich Arrays an. In dem von mir verlinkten Wikipediaartikel ist von einer zweidimensionalen Anordnung in Tabellenform die Rede; bitte beachte dass eine solche Tabelle mit einer Tabelle meiner geliebten Datenbanken wenig gemeinsam hat.

Ja, es ist eine Art Schachbrett.

Wenn meine Vermutung zutrifft, dann vermute ich aus Deinen Angaben, dass Du ein Raster mit 320 Zeilen und 320 Spalten hast, die Darstellung des Gebildes mit genau einem Pixel pro "Feld" wäre somit ein Quadrat mit 320 Pixel Kantenlänge. Ich sehe in dieser Darstellung kein Problem. Wenn es eines wäre, so wären weitere Informationen sehr hilfreich.

Stimmt, aber da eine Darstellung mit einem Pixel pro Feld kaum übersichtlich wäre, muss ich die Felder größer darstellen. Und bei einer Feldgröße von 10x10px wäre es schon eine Kantenlänge von 3200px. Leider schafft das mein Monitor nicht ;-)

Dabei werden, um zur nächst höheren Ebene zu kommen immer 4 Felder zusammengefasst. Genauer: Wenn ich mich  in der untersten Ebene mit 102400 Feldern befinde und in die nächst höhere  aufsteige, werden die Felder 1, 2, 51201, 51202

Warum ausgerechnet diese? Und wie zählst Du durch? Dies dürfte eine Kernfrage Deines Problemes sein.

Das war ein Denkfehler meinerseits. Anstatt die Wurzel zu ziehen, um den "Wert" des erste Feldes der zweiten Zeile zu bekommen, habe ich durch 2 geteilt. Man müsste also nicht die Felder 1, 2, 51201, 51202 zusammenfassen sondern die Felder 1, 2, 321, 322.
Ich zähle von links oben nach rechts unten durch, also das erste Feld der ersten Zeile ist Feld eins, das letzte Feld 320. Das erste Feld der zweiten Zeile ist dann 321, das letzte 640.

Wenn Du diese Werte wirklich in einer Datenbank im oben von mir angesprochenen Sinne abspeichern willst, so bietet sich eine Tabelle mit drei Spalten an:

1. x-Koordinate (Spalte)
2. y-Koordinate (Zeile)
3. Farbwert

Als Primärschlüssel könntest Du entweder ein weitere Spalte verwenden oder auch den kombinierten Index über die ersten beiden von mir genannten Spalten. Da Dein Gebilde seine Größe nicht ändert hast Du eine Tabelle mit 102400 Datensätzen. Dies stellt für ein normales DBMS überhaupt kein Problem dar.

Was meinst du mit einem kombinierten Index?

Wenn Du für die Ausgabe mehrere Deiner "Felder" zusammenfassen willst, so benötigst Du nur eine entsprechende Vorschrift, z.B. vier im Quadrat nebeneinander liegende Punkte bzw. warum nicht gleich ein Quadrat mit einer Kantenlänge von 16 ("Feldern").

Das war mit den Ebenen gemeint. Die unterste Ebene wäre die bei der ein Feld bei der Ausgabe einem Eintrag in der Datenbank entspricht. Die nächsthöhere würde 2x2 Feldern entsprechen, die nächste 4x4. Für die 5. Ebene würden sich daraus ergeben, dass ein angezeigtes Feld 16x16 Feldern der untersten Ebene entspricht und die ausgegebene Tabelle eine größe von 20x20 Feldern hat. Dies dürfte als oberste Ebene passend sein

Es sollte möglich sein, mit einer cleveren SQL-Anweisung Deine 102400 Datensätze auf die von Dir gewünschten 400 Datensätze zu reduzieren (z.B. mit einem Mittelwert). Alternativ könntest Du dies auch in der API (d.h. Deinem Skript, dass auf diese Daten zugreift) tun.

Also, ich muss sagen, dass ich keine Ahnung habe, wie ich das in eine passende SQL-Anweisung verpacken sollte, deshalb war meine Überlegung die Ebenen einzeln in Datenbank-Tabellen zu speichern. Natürlich wäre es wohl performanter und wartungsfreundlicher alle Daten in nur einer Datenbank-Tabelle zu speichern.

Andererseits könntest Du die Daten ganz normal in einer Datei speichern, z.B. in einem Bildformat. Dann hast Du überhaupt kein Problem mit der Ausgabe, Du gibst einfach das Bild aus. Bei einer Datenänderung änderst Du den Farbwert am entsprechenden Punkt. Dazu greifst Du mit der Programmiersprache Deiner Wahl auf die entsprechende Funktion der Dir zur Verfügung stehenden Grafikbibliothek zu. Wenn Du noch nicht weißt, wie das geht, dann frage einfach nach. Wir helfen in einem solchen Fall gerne.

Da gäbe es allerdings ein Problem mit der Manipulation der Daten. Da das ganze wie gesagt nur lokal laufen soll, hatte ich geplant für die Felder der Ausgabetabelle ein onClick-Event einzufügen und so eine schnelle Manipulation zu erlauben. Bei einer Ausgabe als Bild müsste ich wohl entweder eine zusätzliche Eingabemaske einfügen, mit der durch eingabe des x und y Wertes die Manipulation stattfindet, oder ich bräuchte noch eine Imagemap für das Bild. Das wäre aber wohl vom Aufwand her nicht gerade die beste Lösung.

Du solltest zunächst folgende Fragen klären:

1. Die Speicherung Deiner Daten, daraus resultiert der Zugriff auf die Daten.
2. In welcher Form möchtest Du Deine Daten ausgeben.
3. Welche Verarbeitung der gespeicherten Daten ist dazu erforderlich.

das klassische EVA-Prinzip. Die Speicherung Deiner "Ebenen" sollte nicht erforderlich sein, denn diese Information ergibt sich ja aus Deinen Rohdaten. Je nach Zugriff könnte es aus Performancegründen sinnvoll sein, diese "Ebenen" zwischenzuspeichern. Dazu wären mehr Informationen notwendig, was Du mit diesen Daten vorhast, wie oft diese sich ändern, wie oft diese Daten gelesen werden ...

Ich hoffe, das habe ich alles jetzt schon oben geklärt. Ich sollte vielleicht noch erwähnen, dass ich Dantenbank eine mySQL-DB verwende und zur verarbeitung der Daten PHP.

Damit wir Dir besser und zielgerichteter helfen können, solltest Du Informationen nachlegen und vielleicht einen angemessenen Themenbereich wählen. Ich kann mir durchaus vorstellen, dass etliche Stammposter hier den Themenbereich "Datenbanken" ausblenden.

Vielleicht wäre Programmiertechnik als Themenbereich, so wie du es jetzt gewählt hast, besser gewesen, aber ich sehe die Hauptschwierigkeit eben nur in der Art der Speicherung der Daten, nicht so sehr in der Aufbreitung.

Freundliche Grüße

Vinzenz

Danke für die Mühe.

Gruß
Carl

[Vinzenz Mai]

Hallo Carl,

Der Grund, wieso ich als Themenbereich Datenbanken gewählt habe ist, dass ich den Kern des Problems in der Speicherung der Daten in der Datenbank sehe. Aber zunächst erkläre ich wohl besser, worum es mir genauer geht:

[...] Da nur für den lokalen Einsatz bestimmt, muss ich nicht unbedingt auf die Performance achten,

doch nicht bei Spielen. Da geht Performance über alles ;-)

aber die Ausgabe von über 100000 Datensätzen in Form einer Tabelle (das "Spielfeld") würde dann doch meine Geduld etwas zu sehr strapazieren.
Ausserdem möchte ich das ganze dann auch so performant wie möglich haben.

Also doch. *bg*

Man will ja immer nur das beste für sich.

Verabschiede Dich von PHP. Setze eine andere Sprache ein, z.B. C oder was dort im Thread noch alles empfohlen wird :-))

Ja, es ist eine Art Schachbrett.
Stimmt, aber da eine Darstellung mit einem Pixel pro Feld kaum übersichtlich wäre, muss ich die Felder größer darstellen. Und bei einer Feldgröße von 10x10px wäre es schon eine Kantenlänge von 3200px. Leider schafft das mein Monitor nicht ;-)

Na ja, aber 3 Pixel Kantenlänge sollten noch drin sein.

Dabei werden, um zur nächst höheren Ebene zu kommen immer 4 Felder zusammengefasst. [...] Man müsste also nicht die Felder 1, 2, 51201, 51202 zusammenfassen sondern die Felder 1, 2, 321, 322.
Ich zähle von links oben nach rechts unten durch, also das erste Feld der ersten Zeile ist Feld eins, das letzte Feld 320. Das erste Feld der zweiten Zeile ist dann 321, das letzte 640.

Brr, warum nicht von 0 an. Das ist in Programmierkreisen viel naheliegender *g*. Wie ich bereits in meinem ersten Posting ausgeführt habe, ist es meiner Meinung nach sinnvoller in Zeilen und Spalten zu rechnen als in durchnumerierten Zellen. Das wird fast der einzige Punkt bleiben, wo man ohne Verlust wunderbar flexibel bleiben kann. Deine "Ebenen" stelle ich mir als Zoomstufen vor. Für die erste Stufe ergäben sich bei einer Zählung von 0 an (für Spalten und Zeilen) folgende vier Zellen:

(2s, 2z), (2s+1, 2z), (2s, 2z+1), (2s+1, 2z+1), wobei s und z jeweils von 0 bis zur (Anzahl(Spalten bzw. Zeilen)/2)-1 laufen. Den Transferschritt auf Numerierung von 1 an wirst Du selbst hinkriegen.

Die weiteren "Ebenen" lassen sich analog berechnen.

Wenn Du diese Werte wirklich in einer Datenbank im oben von mir angesprochenen Sinne abspeichern willst, so bietet sich eine Tabelle mit drei Spalten an:

1. x-Koordinate (Spalte)
2. y-Koordinate (Zeile)
3. Farbwert

Aus Performancegründen solltest Du ausnahmsweise Deine "Ebenen" ein einzigesmal berechnen und in eigenen Spalten abspeichern. Diese Redundanz bringt Dir Performance. Schließlich sind _alle_ DB-Operationen im Spielfeldbereich UPDATE-Anweisungen. Es ist überflüssig, den Datenbankserver damit zu beschäftigen, immer wieder die gleichen vorher bekannten Werte zu berechnen. Mach' dies nur einmal, bei der Initialisierung des Spielfeldes bzw. Installation des Spieles.

Für jede Zoomstufe (Ebene) füge der Tabelle zwei weitere Spalten hinzu, die effektive Spalten- und Zeilennummer der Zelle in dieser Ebene.

Als Primärschlüssel könntest Du entweder ein weitere Spalte verwenden oder auch den kombinierten Index über die ersten beiden von mir genannten Spalten. Da Dein Gebilde seine Größe nicht ändert hast Du eine Tabelle mit 102400 Datensätzen. Dies stellt für ein normales DBMS überhaupt kein Problem dar.

Was meinst du mit einem kombinierten Index?

Ein Index über zwei Spalten: x- und y-Koordinate.

Also, ich muss sagen, dass ich keine Ahnung habe, wie ich das in eine passende SQL-Anweisung verpacken sollte, deshalb war meine Überlegung die Ebenen einzeln in Datenbank-Tabellen zu speichern. Natürlich wäre es wohl performanter und wartungsfreundlicher alle Daten in nur einer Datenbank-Tabelle zu speichern.

Mit meiner oben skizzierten Idee kannst Du einfach mit GROUP BY über die Spalten- und Zeilennummer der entsprechenden Ebene die zu einer Zelle dieser Ebene gehörenden Zellen zusammenfassen. Mit welcher Aggregatsfunktion Du den effektiven Wert in der Zoomstufe berechnest, bleibt Dir überlassen. Ob es sich lohnt, die effektiven Werte eigens zu speichern, das hängt wiederum von der Häufigkeit der Änderungen und des Auslesens ab. Dazu kann man Dir keinen allgemeingültigen Tipp geben. Falls Du die Daten speicherst, würde ich Dir in diesem Spezialfall wiederum dazu raten, diese Daten (redundant) in dieser Tabelle zu speichern. Vermeide Joins aus Performancegründen :-)

Puh, ich stelle fest, dass ich hier viele Tipps gebe, die das genaue Gegenteil davon sind, was ich normalerweise schreibe. Ich möchte deswegen herausstreichen, dass gerade die Performancegründe, die Abgeschlossenheit des Systems (keine INSERT-Operationen, keine DELETE, nur UPDATE) mit ausschlaggebend dafür sind. Das ganze ist _keine_ typische Datenbankanwendung.

Beim bisherigen Kenntnisstand, genauer gesagt den fehlenden Informationen, fürchte ich, dass die DB der Performancekiller schlechthin bei dieser Anwendung ist. Ist Dein Spiel jedoch als Multiuseranwendung ausgelegt, so kann die DB kompliziertes Locking ersparen.

Viel Spass bei Deinem Projekt!

Vinzenz

[Matzberger Marcus]

Hallo,

Die Umsetzung. Ich hatte mir schon überlegt, für jede Ebene eine Tabelle zu erstellen, aber ich weiß nicht, wie ich dann die Tabellen miteinander Verknüpfen soll.

Wie Vinzenz in seiner ausführlichen Antwort bereits gesagt hat brauchen wir für einen Vorschlag weitere Angaben.
Je nach Einsatzzweck und verfügbarer Techniken (Welches DBMS, welche weitere Verarbeitung, Performance) käme evtl. auch die hierarchische Darstellung in Frage. Zu jedem von dir definierten Feld hinterlegst du das in der Hierarchie höhergelegene. Die Abfrage selbst sieht dann in einem Beispiel für Oracle etwa so aus:

SELECT employee_id, last_name, manager_id, LEVEL
FROM   employees
CONNECT BY PRIOR employee_id = manager_id;

Wobei in der Tabelle für jeden Angestellten (employee_id) der zugehörige Vorgesetzte (manager_id) hinterlegt ist. Das Ergebnis sieht dann in etwa so aus

EMPLOYEE_ID LAST_NAME                 MANAGER_ID      LEVEL
----------- ------------------------- ---------- ----------
        101 Kochhar                          100          1
        108 Greenberg                        101          2
        109 Faviet                           108          3
        110 Chen                             108          3
        111 Sciarra                          108          3
        112 Urman                            108          3
        113 Popp                             108          3
...

wobei LEVEL die zugehörige Hierarchieebene angibt

Grüße
Marcus