Checkboxen im PHP mit SQL

[Raketentheoretiker]

Checked alleine würde ich jedenfalls nicht als der Beschreibungssprache zugehörig, sondern als Attributwert bezeichnen. Und das ist eindeutig ein Datum.

Und wenn es keine Attribute gibt?

Natürlich ist es Unsinn, etwas wie den String checked="checked" in eine Datenbank, womöglich sogar noch in ein Feld namens is_checked einzutragen. Ich denke, darüber braucht man nicht streiten. Hier genügt true oder false, bei rudimentären Datenbanken (oder Datenspeichern) die den binären Datentyp nicht unterstützen, meinetwegen 1 oder 0. Jede Erweitung auf andere mögliche Werte verursacht „Kosten“.

Allerdings hat hier das w3c schon Mist gebaut. Etwas wie checked="STRING" hätte niemals genormt werden dürfen, wenn man es gleichzeitig (und insoweit sinnvoll) als boolean definiert.

Kommen wir zu der aufgekommenen Frage, ob es wohl sinnvoll sei, HTML in Datenbanken einzutragen.

Hier kann man durchaus streiten, es kommt aber auf den Anwendungsfall an. Geht es - wie im Falle der Checkbox - um eine Erfassung eingegebener Daten, dann verbietet sich das selbstverständlich - und ich habe durchaus sehr große Schwierigkeiten damit, zu begreifen, wie man auf eine andere Idee kommen könnte. Ganz anders sieht es aus, wenn man aus Performancegründen (fast) ganze Webseiten wegspeichert, was ja so manches (von verschiedenen auch verschieden bewerteten) CMS, Blog- oder Redaktionssystem macht. Hier würde ich einfach darauf abstellen, dass diese im Hinblick auf das „meistverfügbare“ eben kurzerhand eine SQL-Datenbank benutzen (man kann das auch mit strengem Blick „missbrauchen“ nennen), weil (womöglich, es geht ja um fremde Server) nichts anderes (hier ein simpler Key-Value-Speicher) da ist. Freilich könnte man auch einfach das Dateisystem hernehmen, da schmerzt aber manche (im Hinblick auf die Blockgröße) die ineffektive Ausnutzung des Speicherplatzes oder diese haben Probleme mit Rechten zu lösen (Deren Logik bei den üblichen Nutzungen einer SQL-Datenbank mit dem selben Zugangsdatenpaar für Reaktion, Abruf, Moderation, … aber auch extern geschaffen werden muss). Auch darf man nicht vergessen, dass die SQL-Datenbank womöglich „sowieso“ benutzt wird und man also aus nachvollziehbaren Gründen („Vereinfachung von Backup und Wiederherstellung“ könnte man nennen) eine Fraktionierung (Hier: Verteilung) der Datenhaltung vermeiden will. In solchen Fällen kann es sinnvoll sein, direkt HTML (und damit die Vorbelegung von Formularen, siehe checked) in einer Datenbank abzulegen. Das mag ein Bruch mit der „reinen Wissenschaft“ sein, erscheint aus Performancegründen, wegen der einfacheren Handhabung und der fixierten Vorbestimmung (Redaktionssystem für Webseiten, CMS, Blog) aber als „tragbar“. Sonst müsste man die Webseiten (oder deren Teile) aus Datenschnipseln zusammenbauen, was einige „Kosten“ verursachen kann.