nicht angemeldet
Verständnisproblem: JOINS MySQL
Hallo.
Ich verzweifel völlig.
Ich bin darbei mich mich mit der Normalisierung von Tabellen zu beschäftigen und mit den Dingern die sich JOINS nennen.
Ich check das ganze einfach nicht.
Bisher habe ich eine Tabelle mit 40 Einträgen.
ID,Benutzername, Name, Vorname, Straße, PLZ, Hausnummer, ICQ, MSN, email, AIM, Geburtsdatum, Anmeldedatum, Status, Aktivier ...u.s.w noch einen Haufen anderer Einträge.
Jede ID gibt es nur einmal und ist als Auto_increment und Primärschlüssel gesetzt.
Meine Seite ist (ganz grob) so aufgebaut:
<?php
$place=$_GET['place'];
?>
<html>
<head></head>
<body>
<p>
<a href='index.php?place=home'>Home</a>
<a href='index.php?place=about'>About</a>
<a href='index.php?place=kontakt'>Kontakt</a>
</p>
<?php
if($place=='home')include('home.php');
if($place=='about')include('about.php');
if($place=='kontakt')include('kontakt.php');
?>
</body>
</html>
Also je nach Seite die includet wird, brauche ich auch andere Daten aus der Datenbank. Allerdings gibts auch ein paar Daten die ich auf jeder Seite brauche und ein paar Daten die ich einfach nur aus mehreren brauche.
Wie soll ich das ganze machen? Also es sidn mindestens 40 Einträge aber werden sicher noch mehr in Richtung das doppelte. Ich würde die sonst alle in eine Tabelle schreiben und so abfragen:
"SELECT das,was,ich,brauche
FROM tabelle
WHERE id='$id'";
Die $id wird vorher noch aus der aktuellen Session herrausgelesen.
Die Daten in der Tabelle ändern sich fast täglich durch Cronjobs.
Das heißt das oft drauf zugegriffen werden muss.
Alles in eine Tabelle kommt mir irgendwie übertrieben vor.
In den meisten Spalten stehen nur INT Werte. Das sind auch die die sich ständig ändern werden.
Auch wenn nichts drinsteht, also der Wert 0, wird dieser wert 0 ausgelesen und für manche Berechnungen benötigt.
Ich versteh nicht ganz wie mir da JOINS jetzt helfen sollen.
Ich habe schon etliche Tutorials druchgelesen auch das von SELFHTML, Vinzent Mai und das alles, dazu gabs auch noch einen Artikel über erweiterte JOIN Funktionen. Google hat mir auch einiges geliefert aber überall bleib ich stecken.
Ich brauche die Adam und Eva Version -.-'...
Hoffe ihr könnt mir helfen...
danke...
Mark
-
Hi,
Bisher habe ich eine Tabelle mit 40 Einträgen.
unter "Eintrag" verstehe ich einen Datensatz. Meinst Du Spalten?
Wie soll ich das ganze machen? Also es sidn mindestens 40 Einträge aber werden sicher noch mehr in Richtung das doppelte.
Welcher Art sind diese Daten? Wie lassen sie sich abstrahieren? Die Werte welcher Daten sind gleichförmig? Und: In welcher Weise verändern sie sich (strukturell)?
In den meisten Spalten stehen nur INT Werte. Das sind auch die die sich ständig ändern werden.
Das scheinen schon mal grob Werte zu sein, die sich 1:n auslagern lassen.
Auch wenn nichts drinsteht, also der Wert 0,
0 ist nicht nichts. NULL ist nichts.
Ich brauche die Adam und Eva Version -.-'...
Such mal nach "SQL in 21 Tagen".
Cheatah
--
X-Self-Code: sh:( fo:} ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes-
Hi.
unter "Eintrag" verstehe ich einen Datensatz. Meinst Du Spalten?
Ja Spalten meine ich.
Welcher Art sind diese Daten? Wie lassen sie sich abstrahieren? Die Werte welcher Daten sind gleichförmig? Und: In welcher Weise verändern sie sich (strukturell)?
Es sind Zahlenwerte die sich durch Skripte, die der eingeloggte Besucher ausführt steigern und sinken.
In den meisten Spalten stehen nur INT Werte. Das sind auch die die sich ständig ändern werden.
Das scheinen schon mal grob Werte zu sein, die sich 1:n auslagern lassen.
Was bringt mir das und wie?
Auch wenn nichts drinsteht, also der Wert 0,
0 ist nicht nichts. NULL ist nichts.
Ja und diese 0 brauche ich falls sie "vorhanden" sind.
Ich brauche die Adam und Eva Version -.-'...
Such mal nach "SQL in 21 Tagen".
Ich guck mal nach.
Danke.
Mark
-
-
Moin!
Ich bin darbei mich mich mit der Normalisierung von Tabellen zu beschäftigen und mit den Dingern die sich JOINS nennen.
Erst die Normalisierung. Dann Joins. Nicht alles gleichzeitig.
Bisher habe ich eine Tabelle mit 40 Einträgen.
ID,Benutzername, Name, Vorname, Straße, PLZ, Hausnummer, ICQ, MSN, email, AIM, Geburtsdatum, Anmeldedatum, Status, Aktivier ...u.s.w noch einen Haufen anderer Einträge.Das sind alles Daten, die man nicht durch Normalisierung in andere Tabellen auslagern und per JOIN dann wieder hinzutexten kann - bzw. sollte. Eine ID steht für genau eine Person, die gewisse einmalige Attribute hat.
Einzig Dinge wie EMail-Adressen gibts eventuell mehrfach. Wobei es davon abhängt, ob du (bzw. die Person selbst) es erlaubst, mehr als eine EMail einzutragen. Wenn ja, gehörten die Mailadressen in eine separate Tabelle, mit der Verknüpfung auf die ID. Wenn nein, gehört die eine Mailadresse genau so in die Haupttabelle, wie sie jetzt da steht.
Also je nach Seite die includet wird, brauche ich auch andere Daten aus der Datenbank. Allerdings gibts auch ein paar Daten die ich auf jeder Seite brauche und ein paar Daten die ich einfach nur aus mehreren brauche.
Ja und? Das hat erstmal keine Auswirkungen auf dein Datenbank-Modell und die Normalisierung.
Wie soll ich das ganze machen?
Normalisiere dich nicht zu Tode. Und optimiere nichts, bevor du nicht einen Mechanismus eingebaut hast, mit dem du den Erfolg oder Mißerfolg der Optimierungsmaßnahmen belegen kannst. Was wiederum bedeutet, dass du ein Kriterium festlegen mußt, was durch die Optimierung verbessert werden soll.
Also es sidn mindestens 40 Einträge aber werden sicher noch mehr in Richtung das doppelte.
Wenn alle diese Einträge in einer 1:1-Beziehung zur ID stehen: Was sollte man daran normalisieren und joinen?
Die Daten in der Tabelle ändern sich fast täglich durch Cronjobs.
Ja und?
Das heißt das oft drauf zugegriffen werden muss.
Das einzige Problem, das auftreten könnte: Wenn ständig geschrieben und gleichzeitig auch ständig gelesen wird in der Datenbank, dann kommen sich die beiden Vorgänge in die Quere und sorgen für schlechte Performance.
Aber wie oben erwähnt: Optimiere nichts, was du nicht messen kannst. Und auch nichts, was sich noch nicht als Problem herausgestellt hat.
Alles in eine Tabelle kommt mir irgendwie übertrieben vor.
Wenn deine Daten danach sind, ist das eben so.
In den meisten Spalten stehen nur INT Werte. Das sind auch die die sich ständig ändern werden.
Ja und? Welcher Art sind deine Werte? Kann ein und derselbe Wert mehrfach einer ID zugeordnet werden (1:n), oder können gar mehrere IDs mehrere Werte und umgekehrt mehrere Werte auch mehrere IDs zugewisen sein (n:m)? Würde es überhaupt sinnvoll sein, einem Wert erstmal eine Zuordnungs-ID zusätzlich zuzuweisen?
Auch wenn nichts drinsteht, also der Wert 0, wird dieser wert 0 ausgelesen und für manche Berechnungen benötigt.
Wie schon von Cheatah erwähnt: Eine Tabelle mit INT kennt die Zahl "0" - das ist nicht "nichts steht drin", sondern "Zahl 0 steht drin". Wenn du explizit auch noch "nichts steht drin" speichern willst, mußt du in der Spalte auch "NULL" als Wert erlauben - dann kannst du sowohl "NULL (= steht nichts drin)" als auch "0 (Zahl Null)" speichern.
Wenn deine Spalte nicht NULL speichern kann, dann hast du zwingend immer einen INT-Wert darin. Den Standardwert kannst du auch festlegen, das muß nicht 0 sein.
Ich versteh nicht ganz wie mir da JOINS jetzt helfen sollen.
Ich verstehe es auch nicht. JOINs sind dann notwendig, wenn die Daten danach sind, dass man durch Normalisierung mehr als eine Tabelle benötigt.
Das bedeutet aber, dass vollständig bekannt ist, welche Daten zu speichern sind, und wie sich die untereinander verhalten bzw. aufeinander beziehen.
Für ein Rollenspiel die Charakterwerte eines SC oder NSC in einer Datenbank zu speichern bedeutet immer, dass man einen ganzen Sack voll INT-Werte hat - die aber allesamt in einer 1:1-Beziehung zum jeweiligen Charakter stehen, und somit alle in einer einzigen Tabelle abgelegt werden. Je nach Menge von unterschiedlichen Charakterwerten hat man dann halt mal 40 oder 100 Spalten in dieser Tabelle. Dagegen ist aus meiner Sicht absolut nichts einzuwenden.
Natürlich kann man das auch anders strukturieren: Eine Tabelle für die Charakterdaten wie Name und ID, eine Tabelle mit Attributtypen und deren ID (Stärke = 1, Charisma = 2, Gold = 3), und dann eine Tabelle, in der jeder Charakter-ID eine Attribut-ID sowie der aktuelle Wert zugeordnet wird:
102 - 2 - 6 = Spieler-ID 102, Charisma Wert 6.Problem dabei: Es ist nicht mehr sichergestellt, dass alle Charakterwerte eines Charakters auch tatsächlich existieren, man kriegt also das Problem, die Defaultwerte irgendwie anders ermitteln zu müssen. Und außerdem hat jeder Request auf Charakterdaten nicht mehr nur ein schlichtes SELECT mit genau einer Ergebniszeile pro Charakter zur Folge, sondern erfordert zwei JOINs und ergibt pro Attributwert eine Ergebniszeile - die man umständlicher behandeln muß.
Deswegen eignet sich die "normalisierte" Form eigentlich nur für Dinge wie mitgeschleppte Gegenstände. Denn davon kann ein Charakter keinen, einen oder beliebig viele mitschleppen, die sind auch gleichartig genug, dass so eine Normalisierung sinnvoll ist.
- Sven Rautenberg
--
"Love your nation - respect the others."