Moin moin!
Hallo zusammen,
ich hoffe, dass ich hier im PHP-Forum richtig bin, obwohl die
Frage auch auf MySQL abzielt.
Wird schon passen 
Es geht um eine Grundsätzliche Vorgehensweise, wie Daten
gespeichert werden sollen, die über eine PHP-Maske eingegeben
werden.
[…]
Ich habe leider nicht viel Ahnung von Datenbanken. Mir ist
klar was der Primärschlüssel, Fremdschlüssel, Normalisierung
etc. ist. Aber ich weiß nicht wie viel Arbeit in Bezug auf die
Datenverwaltung ich der Datenbank überlassen muss, und wie
viel ich PHP überlassen muss.
Das kommt vor Allem auf den Anwendungsfall an und kann in den seltensten Fällen pauschalisiert werden. Für eine einfache Datenverwaltung reicht es meiner Meinung aber aus, wenn man der Datenbank lediglich die fertigen INSERTs übergibt, statt mit vordefinierten Queries zu arbeiten, aber auch der persönliche Geschmack des Programmierers spielt hier eine Rolle .
In meinem Fall bekommt jeder User, der sich in das
PHP-Programm einloggt eine Benutzer-ID, die als
Primärschlüssel dient. Damit werden dann auch seine Daten
gespeichert und identifiziert.
Das ist auch gut so, dass mit numerischen IDs gearbeitet wird. Das minimiert die Speicher-Last und maximiert die Geschwindigkeit beim Vergleich mehrerer Tabellen mit Fremdschlüsseln (Texte zu vergleichen braucht einfach länger, als das selbige mit Zahlen zu tun).
Doch wie geht das nun künftig mit weiteren Daten, wie
Kundendaten, Vertragsdaten etc.? Wird ein Vertrag erfasst, so
bekommt dieser einen Primärschlüssel über auto_inkrement
zugewiesen. Damit dieser Vertrag dann auch dem Betreuer und
dem Kunden zugewiesen werden kann, muss in der Vertragstabelle
die Benutzer-ID des User hinterlegt sein und eine
Kundennummer, die wiederum aus einer Kundentabelle hervorgeht.
Ich benötige also immer einen Primärschlüssel, der automatisch
in den Tabellen vergeben wird und die ID des Users, die von
Beginn an fix ist, um die Daten zu selektieren oder wieder zu
verändern. So wäre da mein grundsätzlicher Gedankengang.
Ist das so korrekt?
Ich denke, dass du das schon im Kern ganz gut erfasst hast. Grundsätzlich gibt es zwei Möglichkeiten, die gängig sind, was die Verknüpfung unterschiedlicher Datensätze angeht:
a) Man legt je eine Tabelle für die jeweiligen Datensätze an, in der jeweils eine feste ID vergeben wird (Zahlenwert imt Auto-Increment). Zusätzlich legt man dann eine weitere Tabelle für die Verknüpfung an, in der zwei Felder ebenfalls mit Zahlenwerten stehen. Je Datensatz (bestehend aus den beiden Zahlen) ist dann die Zusammensetzung: IDTabelle1:IDTabelle2. Somit wird über diese „dritte“ Tabelle der eine Datensatz mit dem Anderen verknüpft.
b) Man legt ein Feld in der jeweiligen Tabelle als Fremdschlüssel an und trägt dort die entsprechende ID des zu verknüpfenden Datensatzes ein.
Hier hat a) den Vorteil, dass es eine n:m-Beziehung zwischen den Datensätzen ermöglich, b) hingegen lediglich 1:n. Nachteil ist dafür, dass man bei a) einen weiteren JOIN setzen muss, was bei hohem Datenaufkommen die Last des Servers (wenn auch nur minimal) erhöht. Dafür lassen sich über diese Form aber alle Konstellationen von Verknüpfungen abbilden.
Wichtig ist vor Allem die Verwendung von Indizes auf Fremdschlüssel, um die Suche für die Datenbank zu optimieren. Geschwindigkeitsmäßig nehmen sich die beiden Varianten nur bedingt etwas.
Meines Erachtens bläht sich das ganze nämlich gewaltig auf.
Bei jeglicher Veränderung müssten über SELECT mindestens drei
Primärschlüssel abgefragt werden, noch bevor sich ein
Datensatz eindeutig identifizieren lässt.
Was mache ich da falsch?
Es bläht die Datenbank zwar ein wenig auf, aber das lässt sich anders nunmal kaum lösen. Über einen numerischen Schlüssel zu arbeiten ist schon die kleinste Möglichkeit was den Speicherverbrauch angeht. Wenn man ein entsprechendes Objekt zur Datenbank-Verwaltung nutzt nimmt einem dieses aber oftmals viel Arbeit ab. Dafür muss man einfach mal die verschiedenen Frameworks durchforsten, dann findet man oftmals etwas, was einen sehr einfach mit der Datenbank umgehen lässt.
Ich hoffe, dass das ein wenig hilft?!
MfG
Lutz
