 SQL: Weltkarte  |
Sir Toby
Emporkömmling
Dabei seit: 21.10.2006
Beiträge: 26
 |
|
Hmm, mal ne blöde Frage aber wofür braucht man die Tabelle mit den 62.500 Feldern überhaupt? Die ID der Felder kann man doch berechnen, wenn man sie denn überhaupt braucht. Objekte könnten schon allein durch Speicherung der Koordinaten eindeutig bestimmt werden und solange man nicht jedes Feld einzeln als solches gestalten können soll, würde das eigentlich reichen.
Nur so als Gedanke, wäre vielleicht etwas mehr Rechenarbeit aber weniger Datenbankbelastung und Daten an sich.
Gruß,
Tobi
|
|
Freitag, 30.März 2007 12:50 |
|
|
MoG 
Administrator
Dabei seit: 06.10.2005
Beiträge: 425
Herkunft: Fischbach (Kr. Kaiserslautern)
|
|
Ich nehme an, du redest von der Karten-Tabelle. Nun, du hast vielleicht vergessen, dass ich jedem Feld auch eine Eigenschaft zuweise: den Untergrund.
Der Spieler läuft so über Wasser und Wiesen, was nur durch eindeutige Zuweisung in der Welttabelle geht ^^
Sicher, mit deiner Variante könnte ich alles um eine Spalte reduzieren, in dem ich sage ID = x + 50*y
Wenn man aber direkt x und y-Werte abfragen kann, spart das eine Abfrage. Klingt wenig, aber diese Abfrage würde bei jedem Schritt auf der Weltkarte folgen und das nicht nur von einem User sondern von mehreren gleichzeitig ^^
Wenn ich den Spalten x und y jeweils einen Index zuweise und dann über JOIN die Stadt-Daten miteinbinde, ist die Abfragezeit sehr sehr gering
__________________
|
|
|
Freitag, 30.März 2007 16:11 |
|
|
Sir Toby
Emporkömmling
Dabei seit: 21.10.2006
Beiträge: 26
Themenstarter 
|
|
Gut, aber wenn die Karten-Tabelle wie oben beschrieben nur aus x | y | field_id bestehen soll, kannste dir das auch sparen, da du diese Infomationen jederzeit berechnen kannst, die Kartengröße wäre dann auch sehr variabel.
In dem Fall würde dann einie einzige Tabelle reichen, in der die Objekte der Welt mit field_id festgehalten werden (darunter würde dann auch der Untergrund gehören).
Gruß,
Sir Toby
|
|
|
Freitag, 30.März 2007 18:47 |
|
|
MoG
Administrator
Dabei seit: 06.10.2005
Beiträge: 425
Herkunft: Fischbach (Kr. Kaiserslautern)
|
|
Wenn ich DICH jetzt richtig verstehe *g* bräuchte ich ja nochmal eine Tabelle mit 62.500 Einträgen, wo ich die field_id einer oberfläche zuordne, oder oO
__________________
|
|
|
Freitag, 30.März 2007 18:49 |
|
|
MoG
Administrator
Dabei seit: 06.10.2005
Beiträge: 425
Herkunft: Fischbach (Kr. Kaiserslautern)
|
|
Mmh, nehmen wir mal folgenden Fall:
Die Tabelle "map" mit den spalten | x | y | TRALALA |
Tralala stehe in meinem Lösungsvorschlag für Untergrund-IDs. z.B. 1 für Wüste, 2 für Wasser etc.
In deiner Variante steht Tralala für eine field_ID, meinetwegen auto_increment oder über eine Funktion.
Ich gehe in allen drei Feldern vom Feld-Typ smallint mit einer max-Länge von 3 aus. Das macht dann pro Zeile 33 Bit. Mal 62.500 ergibt das ca. 2 MB
Mit meiner Lösung wars das dann erstmal.
Du willst nun eine weitere Tabelle, die quasi als Fremdschlüssel die field_id abfragt und mit einer Tabelle "map_untergrund" vergleicht. Ok, setzen wir Wasser als standard. Das Wasser macht auf der derzeitigen Karte ca. 1/3 aus. Also ist die neue Tabelle ca. 41000 Zeilen lang, weiterhin soll diese Tabelle 2 Spalten haben, das macht eine durchschnittliche Speichergröße von 0,9 MB, die ich mir quasi spare ^^
oder hab ich was falsch verstanden 
__________________
|
|
|
Freitag, 30.März 2007 19:03 |
|
|
Sir Toby
Emporkömmling
Dabei seit: 21.10.2006
Beiträge: 26
Themenstarter
|
|
*g* Ne, nur eine Tabelle. Ich skizziers mal etwas.
Map-Tabelle:
FieldID | Untergrund
Und das wars.
Hier im Beispiel jetzt mal einzig und allein für die Beschaffenheit des Bodens. Theoretisch könnte man mit Einführung eines Primärschlüssels (für jedes Objekt bzw. Eintrag in der Tabelle) auch alles andere wie Dungeoneingänge, Städte, etc. speichern (statt Untergrund dann eben das Objekt).
Weiß nicht, ob sich das so lohnen würde, aber ich will weg von dem großen Daten Overhead bei deiner Version. *g* Allerdings macht das mit dem Feld TRALALA wieder etwas mehr Sinn. Warscheinlich habe ich field_id falsch interpretiert. 
Nur meine Version ließe sich ohne jeden Aufwand beliebig erweitern.
Gruß,
Sir Toby
|
|
|
Freitag, 30.März 2007 19:18 |
|
|
MoG
Administrator
Dabei seit: 06.10.2005
Beiträge: 425
Herkunft: Fischbach (Kr. Kaiserslautern)
|
|
Mmh, klingt schon besser.
Allerdings kommt es bei mir zu keinem Overhead. Das würde nur passieren, wenn man ein Feld der Karte löschen würde, was mehr als sinnlos is xD
An den 62500 Einträgen führt aber wohl kein weg vorbei, mmh?
Zudem müsste ich den Feldtyp von FieldID ändern. Oder wie wolltest du die FieldID gestalten. Es gibt zwei möglichkeiten:
a) auto_increment. Wäre einfach, dann hätten wir die IDs von 1 - 625000 Das Problem ist, wie bestimme ich nach einer Bewegung, auf welchem neuen Feld ich mich befinde ^^
b) über eine Funktion. Wichtig dabei ist, dass jeder Wert einmal ist und aus einer Kombination aus x und y besteht. im beispiel oben hatte ich die funktion koord = x + y*50
die is natürlich schwachsinn.
Man nehem als Koordinaten einmal (50 | 1) und einmal (0 | 2) nur als schlechtes beispielt ^^°
man müsste höchstens koord = x + y*251 nehmen, allerdings wird die fieldid bei max-koord (250 | 250 ) 5-stellig -.-
__________________
|
|
|
Freitag, 30.März 2007 20:06 |
|
|
MoG
Administrator
Dabei seit: 06.10.2005
Beiträge: 425
Herkunft: Fischbach (Kr. Kaiserslautern)
|
|
Mmh, wenn ich auf deiner Idee rumhack heißt das nicht, dass ich dagegen bin. Ich zeige eher Interesse und würde es gerne umsetzen, muss es dazu aber selbst erstmal verstehen ^^
Also, das Bild leuchtet schonmal ein. Wenn man nun weiter davon ausgeht, dass wir Wasser als Standard definieren... würde das heißen, nach einem Schritt auf der Karte wird die DB gefragt: Hast du ein Feld mit der ID 3006250? Bei einem Nein gehen wir von Wasser aus?
Gut, dann würde wie gesagt ein Drittel wegfallen, blieben ca. 41.666,Periode 6
Mmh, ich bin einfach noch unentschlossen ^^ Nehmen wir als Fallbeispiel mal die Koords (50|1)
Bei deiner Formel ist die Spaltenzahl = Zeilenzahl, oder? Also hätten wir bei einem Feld von 250*250 Als FeldID 12.251 oder?
Die Spaltenzahl würde sich auch bei neuen Feldern nicht ändern, solange man sich im Rahmen von 250 bewegt... mmh...
Weiterdenken. Eine neue Tabelle mit Städten... Als primary-key hatte ich normal eine fortlaufende ID zum gezielten ansprechen... statt einer auto_increment-ID könnte ich jetzt auch direkt die FieldID nehmen und über JOIN angenehm verknüpfen...
Bei NPC wäre das genauso... Nein, ist es nicht... Es können mehrere NPC in einer Stadt stehen... Für NPC bräuchte ich also eine fortlaufende ID
Dungeoneingänge werden wie Städte behandelt, gleiche Tabelle... Wow, dann wäre wirklich alles abgedeckt ^^
Mmh, wegen NPC: die könnte man ebenfalls wie Städte behandeln, wenn wir von World-NPC ausgehen. Alle anderen NPC werden in einer extra-Tabelle notiert.
Deine Idee gefällt mir sehr gut!
Weiterdenken. Es spricht zwar gegen deinen Vorsatz, die Zeilen der Tabelle zu reduzieren. Aber ich wäre fast dafür, direkt die 500*500 im Stück einzutragen, also 250000 Einträge, bzw. 2/3 davon, also 166.667
Das würde die ständige Abfrage nach jedem Schritt sparen, ob sich der User in einem neuen Quadrant der Karte befindet
ich hab nachgefragt, bis zu 4 Milliarden Einträge kann MySQL ohne Probleme in einer Tabelle verarbeiten ohne merkbare latenz. Das Problem sind die Abfragen, die man mit deiner Methode wohl eleganter lösen könnte.
Du fragst nach einer ID, ich frage nach einer Kombination aus x und y ^^°
__________________
|
|
|
Freitag, 30.März 2007 20:52 |
|
|
Sir Toby
Emporkömmling
Dabei seit: 21.10.2006
Beiträge: 26
Themenstarter
|
|
Hehe, ich habe zu keinem Zeitpunkt das Gefühl gehabt, du würdest "auf meiner Idee rumhacken".
Also deshalb keine Sorge.
Ja, deine Ausführungen treffen so ziemlich in Schwarze.
Bei einer quadratischen Map trifft Spaltenzahl = Zeilenzahl zu, allerdings müssten auch rechteckige Maps möglich sein, lediglich die maximale X-Koordinate bzw. die X-Achse müsste klar definiert/begrenzt sein. Aber das ist denke ich nicht so wichtig.
Wichtig ist viel mehr, was schnell zu verabeiten ist. *g* Und da grüble ich noch.
Das mit den 4 Milliarden Einträgen klingt toll, da kommt's wohl wirklich nur auf die Abfragen an. 
Achso, sollten wir nicht mal das Thema splitten und die letzten Beiträge zu sowas Ähnlichem wie "Map-Diskussion" zusammenfassen? ;D
Gruß,
Sir Toby
//Edit Yeah, ich habe einen Thread. *g* Danke Mog
// Kannst ja auch selbst welche erstellen :p
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Sir Toby: 30.03.2007 21:20.
|
|
|
Freitag, 30.März 2007 21:09 |
|
|
MoG
Administrator
Dabei seit: 06.10.2005
Beiträge: 425
Herkunft: Fischbach (Kr. Kaiserslautern)
|
|
Nun, die Map wird vorerst quadratisch sein
Also, 500 mal 500 Felder
Wir nehmen also für die Formel zum berechnen der FeldID eine Spaltenbreite von 500
*g* x und y sind Elemten der Menge |M = [1;500] Wir lassen die 0 mal weg, wären ja komische Koordinaten ^^
So wie ich das sehe, ist die größte FeldID also 250.000 dann sollte als FeldTyp smallint(6) ausreichen
Mmh, könnte es sonst noch irgendwo Probleme geben? Noch ist nichts umgesetzt, nachher kann alles zu spät sein ^^
Ja, ganz wichtig ist die Umrechnung von FeldID -> (x|y)
Bevor die nicht sitzt ist das Bewegen auf der Karte nicht möglich, es sei denn, wir gehen von einer quadratischen Map aus und überlegen uns einen Algorythmus für die 4 Himmelsrichtungen.
Allerdings wäre mir eine Funktion zum Umrechnen lieber, das hält flexibler
__________________
|
|
|
Freitag, 30.März 2007 21:23 |
|
|
Sir Toby
Emporkömmling
Dabei seit: 21.10.2006
Beiträge: 26
Themenstarter
|
|
Grad mal etwas gefummelt, köntnen die beiden Formeln hinkommen? (Mathe war noch nie meine Stärke)
 |
Quellcode |
1:
2:
|
y = aufrunden(FieldID / Spaltenanzahl)
x = Spaltenanzahl - ((y * Spaltenanzahl) - FieldID))
|
Gruß,
Sir Toby
|
|
|
Freitag, 30.März 2007 21:52 |
|
|
MoG
Administrator
Dabei seit: 06.10.2005
Beiträge: 425
Herkunft: Fischbach (Kr. Kaiserslautern)
|
|
Mmh, habs jetzt mit 6 Beispielen gerechnet, es passt
Problematisch wirds mit dem aufrunden...
Auch bei werten mit Nachkommastelle 2 muss "aufgerundet" werden. In PHP müsste man nach dem Komma abschneiden und grundsätzlich 1 draufaddieren...
Dann steht dem ganzen gedöhns nichts mehr im Wege
Morgen kann es dann an erste gehversuche gehen. Die Map kann ja erstmal "theoretisch" getestet werden. Wir speichern in der Usertabelle die FeldID und generieren eine x-y-Ausgabe mit FeldID zum testen. Wenn das läuft, sehen wir weiter
Randinfo: Wir verwenden jetzt MySQL 5.0.21 max-log
Wenn du Zugang zur Datenbank willst, sags nur, soweit vertrau ich dir noch :p
__________________
|
|
|
Samstag, 30.März 2007 22:07 |
|
|
|
