nicht angemeldet
Performance einer SHOW COLUMNS Abfrage
Hallo Forum,
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).
Dazu habe ich ursprünglich erst einmal eine SELECT FROM ... WHERE ... Abfrage um die Feldinhalte zu bekommen. Nun lässt sich aus diesem Ergebniss durch zB mysql_field_flags schon einiges an nötiger Information beschaffen. (Solange keine Enum-Felder auftauchen oder sonstige "Spezialfelder")
Wenn ich aber ein neues Datenfeld Anlege komme ich an SHOW COLUMNS FROM ... nicht herum. Ich hatte mir überlegt dass per SELECT FROM ... LIMIT 0 zu umgehen, um eine identische Grundinformation zum Modifizieren der HTML-Ausgabe zu haben und somit auch an der Funktion nichts frickeln zu müssen, ich halte dass jetzt dann doch aber für ein wenig widersprüchlich.
Nun frage ich mich: Sollte man nicht generell auf SHOW COLUMNS umsteigen, da diese Abfrage ja eigentlich für solche Zwecke der Tabelleninformation gedacht ist. Ich weiß nicht wie performant mysql_field_flags etc. ist, aber drücke ich mein Programm so unnötig durch 2 MySQL-Abfragen runter?
Danke für Infos!
-
yo,
Nun frage ich mich: Sollte man nicht generell auf SHOW COLUMNS umsteigen, da diese Abfrage ja eigentlich für solche Zwecke der Tabelleninformation gedacht ist.
tuning ist ein schwieriges feld, vielleicht das schwierigste, was dbms betrifft. aber es gibt einen grundsatz, nämlich besteht überhaupt ein bedarf. es ist sicherlich immer richtig in die zukunft zu schauen, nur habe ich meine zweifel, dass du energie in etwas steckst, was unter dem strich dir wenig bringen wird.
anders sieht es aus, wenn du ein vorgehen vereinheitlichen willst. das ist immer eine gute sache. viele wege führen zwar nach rom, aber sich für einen festzulegen, der immer gut funktioniert ist sicherlich nicht schlecht. ich kenne die mysql_field_flags funktion nicht (php ?), aber eventuell benutzt sie genau die gleiche datenbankfunktion.
Ilja
-
Erstmal danke für deine Antwort.
Ich würde das benchmarken, fürchte aber dass unter anderem wegen des Cashings in der Datenbank dies nicht viel bringen würde. Wie kann man denn herausfinden, wie eine PHP-Funktion arbeitet wenn man in diesem Fall C nicht mächtig ist?
Weiß von euch jemand bescheid, ob diese Feldinformationen bei MySQl-Querys automatisch mitgeschickt werden? Ich wüsste auch keine Möglichkeit mir die Ressourceninformationen gezielt in lesbarer Form ausspucken zu lassen, um das auf diese Weise zu prüfen.
Für eine Antwort wäre ich mehr als dankbar.
-
-
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."-
Das ist mir alles durchaus bewusst. Auf diese Art und Weise lese ich auch nur Mindestanforderungen an den Eingebenden heraus. Wie zum Beispiel, dass ein integer-Feld eine Zahl benötigt. Wenn der Administrator in seinem Interface diese Vorgabe gemacht hat, dann ist das schön und gut aber nicht notwendig. Diese kann er dann übrigens auch für ein Sting-Feld tätigen.
Ziel der Anwendung ist es aber gerade sich gegebenenfalls auch "mal eben" an eine externe Datenbank anzuhängen und dort benutzerfreundlich (klicki-bunti) als technisch Unversierter Inhalte zu ändern. Komforteinstellungen wie eine valide Email-Addy-Vorgabe wären dann zusätzlicher Luxus, sind allerdings möglich.
Damit aber eben nicht "Klaus-Peter" in einem tinyint(3) NOT NULL feld landet möchte ich solche Bedingungen wie maximal 3 Zeichen und und eine zahl und nicht leer vollautomatisch zur Vorgabe machen knnen und nicht erst am Admininterface rumfrickeln.
Das bringt mich dann wieder zu meiner ursprünglichen Frage...
Trotzdem danke für deinen beherzten Rat.
-