Frage zu meinem DB Design

Schandi · 24.07.2007, 15:31

Hallo Leute,

ich befinde mich gerade in einer Diskussion mit einem Kollegen aus einer Community, mit dem ich eine PHP/mysql Anwendung für die Tabelle zu einem Strategiespiel erstelle.

Ich möchte alles schön normalisiert haben und möglichst nur das notwendigste in der Datenbank, er dagegen möchte "möglichst viel Logik in der DB"

Beispiel
Ich will eine Tabelle mit den Spielresultaten:

nickname_player1 | nickname_player2 | punkte_p1 | punkte_p2 | datum

und eine Tabelle mit den Spielerdaten:

nickname | bonus_punkte

Er dagegen will bei den Spielerdaten einiges mit rein nehmen, was ich erst mit php ausrechen und dann in die html Tabelle einfügen will.

nickname | anzahl_gespielte_matches | erzielte_punkte | bonus_punkte | gesamtpunkte | punkteschnitt

Er meinte das wäre so übersichtlicher und behauptete:

Zitat:

State of the art ist es halt, möglichst viel Logik in die DB zu verlagern anstatt Scriptprogrammierung mit vielen IFs, Wenns und Abers zu betreiben.

Wie beurteilt ihr diese letzte Aussage? Wird das "in der Praxis so gemacht" bzw. sollte das so gemacht werden?
Er argumentiert, dass er mehr Erfahrung bei Softwarearchtektur hat als ich (was grundsätzlich stimmt).

nikosch · 24.07.2007, 15:38

Hallo Schandi,
Willkommen in unserem gemütlichen Forum.

Hmm, Du hältst Dich sehr bedeckt, was die Art des Spiels angeht (z.B. wieviele Spieler gleichzeitig). Mit den bisherigen Infos sieht das auch nicht gerade nach schön normalisiert aus:

Code:

nickname_player1 | nickname_player2 | punkte_p1 | punkte_p2 | datum

KingCrunch · 24.07.2007, 16:13

Normalisiert wäre eher sowas:

Code:

results
---
user1_id | user2_id | punkte1 | punkte2 | date

users
---
id | name

Von wegen "ohne wenn und aber" lässt sich das alles noch ziemlich locker in SQL umsetzen ohne große "Scriptlogik"

zB Gesamtpunktzahl (etwa) so

Code:

SELECT users.name AS name, SUM(points1.punkte1) + SUM (points2.punkte2) AS punktzahl
FROM users, results AS points1, results AS points2
WHERE users.id = $id AND points1.user1_id = $id AND points2.user2_id = $id

So oder so ähnlich, bin net so SQL-fest, dass es jetzt 10%ig klappen muss, aber die Idee sollte klar sein.

nikosch · 24.07.2007, 16:20

Ich hätte als normalisiert eher betrachtet:

Code:

games
--------
game_id | date

results
-------
game_id | user_id | score

users
------
user_id | nickname | name

Ich wüßte auch nicht, was in diesem Bsp. viel Logik erfordern sollte, was nicht auch das Script ohne Aufwand hinbekommt.
.

agrajag · 24.07.2007, 16:30

Zitat:

Zitat von Schandi

Ich möchte alles schön normalisiert haben und möglichst nur das notwendigste in der Datenbank, er dagegen möchte "möglichst viel Logik in der DB"

[...]

Er meinte das wäre so übersichtlicher und behauptete:

Zitat:

State of the art ist es halt, möglichst viel Logik in die DB zu verlagern anstatt Scriptprogrammierung mit vielen IFs, Wenns und Abers zu betreiben.

Ich glaube ihr redet aneinander vorbei oder er hat keine Ahnung von was er redet. (3. Möglichkeit. Ich hab keine Ahnung.

)

Was hat denn das absichtliche "denormalisiert" speichern (was ja grundsätzlich aus Performance gründen schon Sinn machen kann) mit "viel Logik in der DB" zu tun?
Viel Logik wäre für mich eher die Datenabnk mit Constraints, Triggern, Stored-Procedures - und was weiß ich was es noch für Schweinereien gibt - zuzuballern

Um was geht es deinem Freund denn? Performance oder "Übersichtlichkeit" bzw. leichtere Abfragen? Letzteres kann er auch erreichen indem ihr einfach zusätzlich noch ein paar Views anlegt die euch das abfragen erleichtern. Ich weiß nicht ob MySQL inzwischen Materialized Views unterstützt - aber damit lässt sich vllt. auch noch die Performance hochschrauben?

Vielleicht solltet ihr euch erstmal darüber klar werden was eure Anwendung können muss und was euch wichtig ist.

Schandi · 25.07.2007, 01:11

An einem Spiel sind immer 2 Personen beteiligt.

Der Name in nickname_player1 ist einzigartig und wird als Schlüssel in der Spielerdatenbank benutzt.

@nikosch77: achja - dein vorschlag der Normalisierung ist einleuchtend!

Views funktionieren anscheinend leider erst ab mysql 5 aufwärts(?) Der server auf dem die Anwendung läuft hat aber nur 4.irgendwas

Also der Freund will, dass der PHP Code der die HTML Tabellen erzeugt, leichter zu verstehen ist.
Ich hab da halt eine Abfrage reingeschrieben, die alle Spielresultate holt und daraus Gesamtpunktezahl/Schnitt usw. errechnet. Er will diese Daten gleich in der Datenbank haben. ich bin dagegen, weil durchaus falsche Ergebnisse (per hmtl/php forumlar) in die DB eingegeben werden und man dann an verschiedenen Stelle korrigieren muss.

Performance sollte eingentlich egal sein. Da wird nur ein paar mal täglich was in die Datenbank eingetragen und wenn es hoch kommt ein paar Hundert mal täglich eine dynamische html Seite mit der Tabelle erzeugt.

Danke jedenfalls für die Antworten, da ist schon einiges dabei was ich mir durch den kopf gehen lassen werde.

KingCrunch · 25.07.2007, 01:41

Zitat:

Also der Freund will, dass der PHP Code der die HTML Tabellen erzeugt, leichter zu verstehen ist.

Mit Kommentaren und so weiter immer möglich

Zumal: Komplizierter werden nur die SQL-Statements, nicht aber der PHP-Code.

Zitat:

Da wird nur ein paar mal täglich was in die Datenbank eingetragen und wenn es hoch kommt ein paar Hundert mal täglich eine dynamische html Seite mit der Tabelle erzeugt.

Da macht es eventuell Sinn die Seite zu cachen, bis ein neuer Eintrag hinzukommt.

Zergling-new · 25.07.2007, 11:26

Also wenn die Datenbank so angelegt wird wie dein Kumpel es möchte, ist sie performanter und übersichtlicher, aber eben auch nicht normalisiert, was zur Folge hat, dass sie ohne weiteres inkonsistent werden kann, das heißt Daten doppelt führt, die sich gegenseitig widersprechen. Jeder behauptet da erstmal, das kann nicht passieren. Es passiert aber, ganz bestimmt!

Ich würde das ganze ausnormalisieren, vielleicht nicht unbedingt bis zum letzten, aber doch soweit wie du es vorgeschlagen hast. Das sah doch für den Anfang schonmal ganz gut aus.

Nun hast du eben die Möglichkeit ein wenig Logik an MySQL abzutreten, was den Vorteil hat, dass MySQL schneller ist, der Nachteil ist, MySQL-Berechnungen sind meiner Meinung nach schwieriger zu verstehen (auch wenn sie kompakter sind), was dein Kumpel ja gerade verhindern will.

Um was für Spiele gehts denn?

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
Design und Code Trennen	TeazY	PHP Tipps 2008	29	21.05.2008 12:08
Design		Beitragsarchiv	26	04.06.2005 20:56
mal ne Frage		PHP Tipps 2005	7	14.04.2005 09:46
Technische Frage zur Realisation einer Online-Umfrage	Stefano	PHP Tipps 2005	5	16.03.2005 17:39
Frage zu einer Liste?		HTML, Usability und Barrierefreiheit	2	15.02.2005 16:56
Frage zu Include	Pimbolie1979	PHP Tipps 2005	4	14.02.2005 14:16
Frage zum Design: HTML Formular		HTML, Usability und Barrierefreiheit	11	27.01.2005 22:17
[PHP] Design Schutz für ein Gästebuch	I-Spy	PHP Tipps 2005	5	01.01.2005 11:25
Mit Sessionen das Design wählen lassen.		PHP Tipps 2004-2	8	28.12.2004 08:30
Hallo und Frage zu dynamischer Veränderung in Textfeldern.		PHP Tipps 2004-2	2	27.12.2004 22:29
[Erledigt] Frage zur Funkrionen?		PHP Tipps 2004-2	10	01.12.2004 09:42


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

24.07.2007, 15:38
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.987 PHP-Kenntnisse: Fortgeschritten	Hallo Schandi, Willkommen in unserem gemütlichen Forum. Hmm, Du hältst Dich sehr bedeckt, was die Art des Spiels angeht (z.B. wieviele Spieler gleichzeitig). Mit den bisherigen Infos sieht das auch nicht gerade nach schön normalisiert aus: Code: nickname_player1 \| nickname_player2 \| punkte_p1 \| punkte_p2 \| datum

24.07.2007, 16:13
KingCrunch Erfahrener Benutzer Registriert seit: 13.08.2007 Beiträge: 1.976	Normalisiert wäre eher sowas: Code: results --- user1_id \| user2_id \| punkte1 \| punkte2 \| date users --- id \| name Von wegen "ohne wenn und aber" lässt sich das alles noch ziemlich locker in SQL umsetzen ohne große "Scriptlogik" zB Gesamtpunktzahl (etwa) so Code: SELECT users.name AS name, SUM(points1.punkte1) + SUM (points2.punkte2) AS punktzahl FROM users, results AS points1, results AS points2 WHERE users.id = $id AND points1.user1_id = $id AND points2.user2_id = $id So oder so ähnlich, bin net so SQL-fest, dass es jetzt 10%ig klappen muss, aber die Idee sollte klar sein. __________________ Nicht jeder Fehler ist ein Bug.

24.07.2007, 16:20
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.987 PHP-Kenntnisse: Fortgeschritten	Ich hätte als normalisiert eher betrachtet: Code: games -------- game_id \| date results ------- game_id \| user_id \| score users ------ user_id \| nickname \| name Ich wüßte auch nicht, was in diesem Bsp. viel Logik erfordern sollte, was nicht auch das Script ohne Aufwand hinbekommt. .

25.07.2007, 01:11
Schandi Neuer Benutzer Registriert seit: 24.07.2007 Beiträge: 2	An einem Spiel sind immer 2 Personen beteiligt. Der Name in nickname_player1 ist einzigartig und wird als Schlüssel in der Spielerdatenbank benutzt. @nikosch77: achja - dein vorschlag der Normalisierung ist einleuchtend! Views funktionieren anscheinend leider erst ab mysql 5 aufwärts(?) Der server auf dem die Anwendung läuft hat aber nur 4.irgendwas Also der Freund will, dass der PHP Code der die HTML Tabellen erzeugt, leichter zu verstehen ist. Ich hab da halt eine Abfrage reingeschrieben, die alle Spielresultate holt und daraus Gesamtpunktezahl/Schnitt usw. errechnet. Er will diese Daten gleich in der Datenbank haben. ich bin dagegen, weil durchaus falsche Ergebnisse (per hmtl/php forumlar) in die DB eingegeben werden und man dann an verschiedenen Stelle korrigieren muss. Performance sollte eingentlich egal sein. Da wird nur ein paar mal täglich was in die Datenbank eingetragen und wenn es hoch kommt ein paar Hundert mal täglich eine dynamische html Seite mit der Tabelle erzeugt. Danke jedenfalls für die Antworten, da ist schon einiges dabei was ich mir durch den kopf gehen lassen werde.

25.07.2007, 11:26
Zergling-new Erfahrener Benutzer Registriert seit: 21.05.2008 Beiträge: 9.937	Also wenn die Datenbank so angelegt wird wie dein Kumpel es möchte, ist sie performanter und übersichtlicher, aber eben auch nicht normalisiert, was zur Folge hat, dass sie ohne weiteres inkonsistent werden kann, das heißt Daten doppelt führt, die sich gegenseitig widersprechen. Jeder behauptet da erstmal, das kann nicht passieren. Es passiert aber, ganz bestimmt! Ich würde das ganze ausnormalisieren, vielleicht nicht unbedingt bis zum letzten, aber doch soweit wie du es vorgeschlagen hast. Das sah doch für den Anfang schonmal ganz gut aus. Nun hast du eben die Möglichkeit ein wenig Logik an MySQL abzutreten, was den Vorteil hat, dass MySQL schneller ist, der Nachteil ist, MySQL-Berechnungen sind meiner Meinung nach schwieriger zu verstehen (auch wenn sie kompakter sind), was dein Kumpel ja gerade verhindern will. Um was für Spiele gehts denn?