Phlegma hat geschrieben:Hm, das wird jetzt dann langsam OT
Das sind die besten Diskussionen :)
Phlegma hat geschrieben:Zahlen: 5000 Spieler: 50.000 Planeten, 100.000 Flotten, seehr viele Schiffe. Wichtig ist, dass die Interaktion nicht zu häufig ist, vor allem nicht flächendeckend.
Ja, aber wie willst du das sicherstellen? Ich denke, das Spiel wie ich's vorgeschlagen hatte zu takten, funktioniert einfach nicht. Doch welchen Ansatz sonst? Mir würde noch eine "priority queue" zur "Wiedervorlage" von Aktionen einfallen, doch das enthebt das System ja nicht davon, letztlich doch 100.000 Flotten pro Minute zu bewegen. Oder muss man die Spielregeln so anpassen, dass z.B. jeder der Spieler maximal 3 Flotten pro Minute bewegen darf. Irgendwie finde ich nach wie vor die Idee gut, alles im Hauptspeicher zu halten und so die relativ langsamen Datenbank-Operationen aus der Zeit-Rechnung zu nehmen.
Phlegma hat geschrieben:Beispiel das bereits gezeigte Kampfsystem, das totzdem einen Kampf zwischen mehreren Spielern in zwei Parteien zulässt.
Das habe ich überhaupt nicht verstanden. Willst du da einen Zufallsfaktor einbauen? Was heißt totzählen? Gewinnt in einem Kampf einfach die größere/stärkere Flotte?
Ich wollte ursprünglich bei meiner Regelinterpretation Bündnisse beschreiben, doch das ist schon alles andere als trivial, den Algorithmus zum Aufteilen von N Spielern in N' Fraktionen zu beschreiben, sodass ich denke, dass wäre als Datenbank-Operationen richtig aufwendig.
Phlegma hat geschrieben:Ich komme nochmal zum OR-Mapper zurück. Ich habe grade erst verstanden was "relational" überhaupt bedeutet, so doof sich das auch anhört, aber bisher dachte ich damit sei nur die Tabellenform gemeint. Aber "Relation" heißt ja "Beziehung". Die Tabellen sind verknüpft.
Nein, eine relationale Datenbank besteht schon aus Tabellen (diese heißen verwirrenderweise Relationen) mit jeweils gleich strukturierten Datensätzen (oder Tupeln) auf denen dann Grundoperationen (selection, projection und cartesian product) definiert sind. Die letzte (auch Join genannt) verknüpft die Tupel zweiter Relationen und bildet eine neue Relation mit verknüpfen Tupel. Die Operation drückt dann das, was du als eine Beziehung bezeichnet hast, aus.
Die Relation aus einem Entity-Relationship-Modell ist nicht die Relation einer relationalen Datenbank. Letztere basiert auf der Theorie der relationalen Algebra. Und weil sie so schön theoretisch untermauert ist und Tabellen in vielen Fällen echt praktisch sind, hat sie sich durchgesetzt.
Es gibt noch objektorientierte, deduktive, hierarchische oder Netzwerk-Datenbanken.
Phlegma hat geschrieben:Dabei fällt mir auch, dass ich bisher nur einen Typ von Verknüpfung brauche: One to Many (to Many).
Das verwundert mich, denn z.B. ein Bündnis wäre eine N:M-Beziehung. Was du als Vorteil zu erkennen glaubst, ist die Beschränkung einer relationalen Datenbank, gar keine N:M-Beziehungen modellieren zu können. Man muss sich dort mit einer Hilfstabelle und zwei 1:N-Beziehungen behelfen. Auf die Abstraktion einer N:M-Beziehung verzichten zu wollen, ist IMHO ein Schritt in die falsche Richtung.
Phlegma hat geschrieben:Habe auch ein paar schöne Berechtigungsdiagramme für User gesehn, dafür bräuchte ich schon eher einen OR-Mapper, fragt sich nun welcher. Bei diesen Bedingungen kann ich sogar auf die Transaktionen verzichten. Da verändert sich nicht viel gleichzeitig.
Das klingt für mich auch äußerst fragwürdig.
Phlegma hat geschrieben:Ich suche also ein Framework, das mir bereits eine Userverwaltung bietet, an welches ich dann meinen speziellen Mapper anbauen kann.
Django bietet dir eine Benutzerverwaltung, allerdings erfordert der ORM, dass du nach Änderungen immer explizit speichern musst, was ich mit dem Attribut primitiv bezeichnen würde.
Eigentlich will man IMHO einen "persistence context" am Ende einer Operation automatisch sichern können und sich nicht Gedanken darüber machen müssen, was man nun wo wie geändert hat. Was Relationen zwischen Modellen angeht, wird Django 1.1 für dich ausreichend sein.
Stefan