Hallo
ich habe ein Problem mit dem enum Datentyp in mySQL. Und zwar moechte ich auch in der Lage sein, dort Werte zu speichern, die Hochkommata enthalten. Zum Beispiel:
Kein Problem bei keinem mir bekannten Datenbankmanagementsystem. Für so etwas gibt es Escapemechanismen.
O'Neils
O'Learies
O'BriansNun ist es ja so, dass der enum Datentyp Hochkommata als Begrenzer fuer die einzelnen Werte einsetzt. Ansich ja kein Problem, mit addslashes() kann ich in PHP diese Hochkommata ja codieren, so dass sie mir keine Probleme machen. Anschliessend speichere ich diese Werte in der Datenbank.
Verwende lieber mysql_real_escape_string(). Beachte Beispiel 3, das Zusammenspiel mit den schrecklichen Magic Quotes.
Wenn ich nun die Werte von der Datenbank abfragen moechte, nutze ich einfach stripslashes() um sie wieder los zu werden.
Das ist einfach fehlerhaftes Vorgehen. Es gibt kein Hochkomma (auch keine Hochkommata) im Rückgabewert, den es loszuwerden gälte. stripslashes() ist überflüssig. Überlege Dir, aus welchem Grund Hochkommata und ähnliche Zeichen maskiert werden müssen. Überlege Dir, aus welchem Grund MySQL keine Maskierung zurückliefert.
Ist dies im generellen ein guter Ansatz?
Nein.
In der Theorie funktioniert es naemlich ganz gut,
in der Theorie ist er fehlerbehaftet.
aber in der Praxis habe ich es nicht hinbekommen da immer zu viele oder zu wenige backslashes vorhanden waren.
was mich nicht wundert.
- Gedankensprung -
Wie verhalt es sich, wenn meine Wertemenge sehr gross ist, Beispielsweise ich speichere alle Haupstaedte der Welt.
das ist keine sehr große Wertemenge. ENUM hätte damit kein Problem. Ich halte ENUM in diesem speziellen Beispiel für ungeeignet.
Ich moechte nur diese Hauptstaedte in meiner Datenbank haben, da wuerde sich ja auch der enum Datentyp anbieten oder?
Nein. Meiner Meinung nach nicht.
Oder sollte ich lieber eine extra Tabelle erzeugen, die alle gueltigen Staedtenamen enthaelt und dann mit PHP absichern, dass nur gueltige Werte in der anderen Tabelle gespeichert werden?
Nein. Wozu?
Wenn Du z.B. eine Tabelle Länder hast, eine Tabelle Städte, so könntest Du eine Tabelle Hauptstädte haben, in der die ID des Landes und die ID der Hauptstadt (bzw. der Hauptstädte) eingetragen ist. Wo ist das Problem? Ach so ja. Ein Frontend für diese Tabelle ist nicht unbedingt erforderlich. Aktualisierungen werden mit einem kleinen SQL-Skript erledigt. Solche Sachen sind Stammdaten, an denen sich recht selten etwas ändert. Daher hielte ich den Aufwand für die Datenpflege in diesem Bereich klein.
Freundliche Grüße
Vinzenz