Und noch ein kleiner Tip bezüglich Datenbanken. Betreibe Overengineering. Datenbanken zu altern, bzw Änderungen zu machen weil die Anforderungen an die Datenbanken steigen, ist das letzte was du haben willst.
Kann ich nicht bestätigen. Wir haben in der Vergangenheit Änderungen gemacht und erweitern unsere Datenbanken noch immer bei jedem Release für neue Features und ich sehe da überhaupt keine Probleme. Wo genau siehst du da welche?
@webconqueror: Du solltest überdenken, wie du auf existierende eMails prüfst. Beispiel: Ich registriere mich mit
EMail@gmx.de und jemand anderes mit
email@gmx.de. Nach dem aktuellen Code gibt's da keine Zurückweisung.
Und sogar noch schlimmer, was passiert, wenn meine eMail so lautet: " foo' OR 1; -- ". Ihr habt doch sicher mal über SQL-Injection im Studium gesprochen. Solche Eingaben nur im Client zu verhindern ist nicht ausreichend, es kann ja jemand ein Script schreiben und direkt gegen deine Server-Schnittstelle ausführen. Und dann hat deine Datenbank eventuell ein ernstes Problem.
(im Moment fehlen in deinem SQL ohnehin die '' um die eMail, das gäbe fleißig SQL-Errors). Ich habe in meinen Server-Logs z.B. Bots gefunden, die jede Menge generierte SQL-Injections auf diverse Schnittstellen meines Servers abgesetzt haben. Dank sauberem Escape meiner SQL-Parameter war das aber kein Thema für mich.
Generell sollte dein Script nach Möglichkeit nur genau eine Aufgabe erfüllen. Damit ergibt sich das Problem der "mehrere Funktionen" gar nicht. Du kannst aber dennoch natürlich weitere Funktionen anderweitig codieren und prüfen:
myScript.php?type=register
myScript.php?type=login
Außerdem kannst du auf Serverseite prüfen, welche HTTP-Aktion durchgeführt wurde. Eventuell machen ja POST, PUT, DELETE und GET andere Dinge? Ich z.B. nutze für Login/Logout dasselbe Script. Login macht POST, Logout macht DELETE.