nicht angemeldet
Moin!
Ich wollte mich mal erkundigen, wie performant eine SHOW COLUMNS-Abfrage im Vergleich zu mysql_field_*()-Funktionen ist. Ich lese momentan Datensätze aus einer Datenbank aus und modifiziere die HTML-Anzeige anhand von Tabelleninformationen (NOT-Null-Felder werden zu Pflichtferldern etc).
Ich denke, dein Funktionsansatz ist nicht so sonderlich zielführend.
MySQL hat im Prinzip keine existierende Unterstützung für Constraints außer das, was implizit durch MySQL-eigene Mechanismen erzwungen wird (NOT NULL, UNIQUE-Index etc.)
Das wiederum bedeutet, dass es dir eigentlich gar nicht möglich ist, die Constraints-Anforderungen an die Dateneingabe in den Metainformationen deiner Datenbanktabelle zu speichern - es muß somit zwingend eine andere Speicherform gefunden werden.
Darüber hinaus würde ich meinen, dass eine fertig entwickelte Applikation doch ihr in der DB abgelegtes Datenmodell vollständig kennen sollte. Also besteht eigentlich auch gar nicht die Notwendigkeit, für ein DB-Feld "email NOT NULL" erst aus der Datenbank zu erfahren, dass es ein Pflichtfeld ist - das weiß die Applikation im Prinzip schon aus sich heraus selbst.
Die spannende Frage ist nur: Wo speichert man dieses Wissen ab.
Und da kommen wir zu einem Aspekt, den ich mal als Frage formulieren möchte: Wie definierst du ein Pflichtfeld?
Denn es gibt ja durchaus unterschiedliche Ansichten darüber, was ein Pflichtfeld sein kann. Die Datenbank kennt keine "Pflichtfelder", die sieht nur den benutzten Datentyp, das Attribut NULL (oder nicht), und erlaubt auf dieser Basis das Einfügen der Daten (ggf. nach interner Wandlung/Interpretation), oder eben nicht.
Die Applikation und der Benutzer hingegen könnten die übliche Pflichtfeld-Definition annehmen: Ein Pflichtfeld muß mit Zeichen befüllt werden, ein Leerstring ist nicht erlaubt.
Das wiederum widerspricht dem DB-Inhaltsmodell von NULL vs. NOT NULL. Wenn du Strings abspeichern willst, dann benötigst du kein NULL, um Leerstrings abzuspeichern. Ein Pflichtfeld und ein Nicht-Pflichtfeld (wie es der Benutzer sieht) unterscheiden sich also im DB-Typ nicht. Also ist das Abspeichern dieser Tatsache als DB-Feldattribut sachlich falsch.
Andererseits fehlen dir für weitergehende Constraints zumindest in MySQL komplett die Mittel, denn beispielsweise eine Pflicht-Emailadresse läßt sich in MySQL nur als String speichern, aber mir fällt spontan nicht ein, wo du die Tatsache "muß RFC-valide Mailadresse sein" abspeichern würdest. Dasselbe gilt z.B. für Zahlentypen mit eingeschränktem Wertebereich (TINYINT, aber nur Zahlen von 1 bis 49) etc.
Insofern wäre es eine viel bessere Idee, diese Art von Metadaten eben gerade NICHT in der Tabellendefinition zu speichern, sondern in einem Metadatenspeicher. Nun gut, das könnte natürlich wieder eine DB-Tabelle sein, die dann ganz klassisch gelesen wird. Oder es wird einfach direkt in die Skriptlogik implementiert (ich hatte da mal eine nette Check-Klasse geschrieben, der man einfach ein Array mit vorzunehmenden Standard-Tests übergibt, und ggf. noch weitergehende Zusatztests).
Es sei denn natürlich, dass du gerade ein Admin-Interface wie PHPMyAdmin schreibst, dass nicht wissen kann, welche DB-Struktur vorliegt, sondern diese dynamisch ermitteln muß.
- Sven Rautenberg
"Love your nation - respect the others."