Grundsatzdiskussion SELECT *

[SysOp]

Was an SELECT * soll denn nun so grundlegend falsch sein? Mir erschliesst sich nicht wieso SELECT * solch Teufelswerk sein soll.

Anlass meiner Frage ist die Tatsache, dass in einem Thread wieder einmal mehr darauf hingewiesen wurde, wie schlimm SELECT * nicht sei, ohne überhaupt zu wissen, ob z.B. die Notwendigkeit, alle Felder zu lesen, besteht oder nicht. Ob und wie die Ergebnisse dann verifiziert werden war dem Beispiel auch nicht zu entnehmen.
Auffällig war jedenfalls der Hinweis, dass SELECT * sogar falsch sei und das lese ich nicht zum ersten mal!

Bsp.
Ich erlaube dem Admin in nahezu allen meinen Projekten selbst Felder in der Datenbank zu definieren. Meistens fehlen ja wirklich irgend welche Felder, die man dringend benötigen würde.
Da ich dem Anwender ersparen möchte für jedes selbst definierte Feld selbst Hand an den Code legen zu müssen, damit seine Felder auch ausgelesen werden ist ein SELECT * eine ebenso einfache wie unproblematisch funktionierende Abfrage.
Natürlich könnte ich nun jedes Mal den Aufbau einer Tabelle auslesen, den SELECT danach der Reihe nach abarbeiten und im Script mit den Feldnamen Schritt für Schritt zusammenbauen. Tatsächlich macht der Code dann aber auch nichts anderes als ein SELECT *, er wäre nur länger, fehleranfälliger und schlechter lesbar.

Aus reiner Ressourcen-Schonerei (sollte das der Grund sein) macht das Vermeiden eines SELECT * auch keinen wirklichen Sinn.
Im 21`sten Jhd und bei der Performance der aktuellen Server sind Laufzeitdifferenzen im Hunderstel Bereich nichts, was einen merkbaren Unterschied machen würde. Dann müsste ich genauso aus Ressource-Gründen Objekte verteufeln.

Den Grund für einen prinzipiellen Horror, beim Anblick von SELECT * sehe ich einfach nicht.

[h3ll]

Was an SELECT * soll denn nun so grundlegend falsch sein? Mir erschliesst sich nicht wieso SELECT * solch Teufelswerk sein soll.

1. Unvorhersehbares Ergebnis.

2. Schlecht lesbarer Code.

3. Mögliche Performance-Probleme.

4. Mögliche Fehler, die dann nicht auffallen.

Ich erlaube dem Admin in nahezu allen meinen Projekten selbst Felder in der Datenbank zu definieren.

Hier muss man zwischen Serveradmin und Anwendungsadmin unterscheiden.

Ein Serveradmin interessiert sich nicht für Spalten der Anwendung.

Ein Anwendungsadmin hat in der Datenbank nichts verloren. Für den stellt die Anwendung eine Administrationsoberfläche zur Verfügung. Und hier werden natürlich keine Spalten angelegt. Denn zur Laufzeit sollte die Datenbank nicht verändert werden.

Meistens fehlen ja wirklich irgend welche Felder, die man dringend benötigen würde.
Da ich dem Anwender ersparen möchte für jedes selbst definierte Feld selbst Hand an den Code legen zu müssen, damit seine Felder auch ausgelesen werden ist ein SELECT * eine ebenso einfache wie unproblematisch funktionierende Abfrage.

Ein Anwender legt keine Spalten in der Datenbank an. Wenn das so ist, liegt ein Fehldesign der Anwendung vor.

Den Grund für einen prinzipiellen Horror, beim Anblick von SELECT * sehe ich einfach nicht.

Ich sehe, dass du offenbar ein Fehldesign mit einem SELECT * umgehen willst. Dann noch ein Negativpunkt für SELECT *: Es ermöglicht/bestärkt so eine falsche Vorgehensweise.

[mermshaus]

Ich würde das Pferd umgekehrt aufzäumen und fragen, worin der Vorteil von SELECT * besteht.

Es mag situative Anwendungen dafür geben, die meinetwegen auch einsichtig sind, aber ich möchte die These in den Raum stellen, dass ein DB-Schema häufig aus Anwendungssicht doch eher starr ist, weil nicht selten eine Menge Logik sehr eng damit verknüpft ist. Mit Änderungen am DB-Schema sind häufig auch Anpassungen in der Anwendung verbunden, weil etwa Models nach dem DB-Schema angelegt sind und dergleichen.

In solchen Fällen mag SELECT * Schreibarbeit sparen, aber das geht sehr unmittelbar auf Kosten der Nachvollziehbarkeit, weil Felder dann schnell auf magische Weise mit Werten gefüllt werden und etwaige Probleme (neues Feld nicht korrekt durchimplementiert) dadurch verdeckt werden könnten.

Man erzeugt damit einen kognitiven Mehraufwand, weil man es gewissermaßen verhindert, dass das DBMS beim Auslesen gewünschter Felder etwaige Oversights automatisch anmerkt.

Ich würde es vielleicht auch mit INSERT-Queries vergleichen, bei denen man in der Regel auch nicht mit dynamischen/variablen Feldlisten arbeitet.

[fireweasel]

Was an SELECT * soll denn nun so grundlegend falsch sein? Mir erschliesst sich nicht wieso SELECT * solch Teufelswerk sein soll.

Ist es nicht. Es hat sicher seinen Anwendungsbereich. Aber den sollte man besser beschränken (bspw. aufs interaktive Herumprobieren in der Konsolen-Anwendung des Clients).

Da ich dem Anwender ersparen möchte für jedes selbst definierte Feld selbst Hand an den Code legen zu müssen, damit seine Felder auch ausgelesen werden ist ein SELECT * eine ebenso einfache wie unproblematisch funktionierende Abfrage.

Du sparst einmalig (beim Entwurf einer Abfrage) etwas Tipparbeit. Das klingt eher nach Faulheit als nach Einfachheit.

Unproblematisch (in Bezug auf Funktionssicherheit) ist deine SELECT-Anweisung nur, solange sich nichts am Datenbankaufbau oder im Anfrage-Teil nach FROM ändert. Was konkret schiefgehen kann, steht hier geschrieben: https://softwareengineering.stackexc...ractice/234678
Relevante Abschnitte sind "Schema Changes" und "Failure to convey intent".

Für den Fall, dass ausgelesene Datensätze in ein assoziatives Array wandern, hat PHP hat noch eine Extra-Stolperfalle eingebaut: https://softwareengineering.stackexc.../234667#234667

Dass SELECT * auch die Datenbank davon abhalten kann, Indizes zu nutzen, fällt dann auch nicht mehr ins Gewicht.