nicht angemeldet
echo $begrüßung;
» Die Ergebnismenge klein zu halten ist ein legitimes Argument, wenn es sich um potentiell große Datenmengen handelt. Ein, zwei überflüssige Spalten mit ein paar wenigen Bytes drin, sind für mich aber kein schlagkräftiges Argument gegen SELECT *.
Dann hast Du noch nie an einem größeren Projekt/Produkt gearbeitet, bei dem viele unterschiedliche Leute auf viele unterschiedliche Arten und Weisen auf viele unterschiedliche Tabellen zugreifen.
Ich meinte die Anwendungsfälle, in denen vorhersehbar ist, dass sie klein bleiben. Größere Projekte verlangen selbstverständlich andere Herangehensweisen. Warum sollte man sich nicht zu Hause ein All-in-One-Gerät zur Telekommunikation hinstellen, wenn man prinzipiellen Bedarf dafür hat? In einer Firma ab einer gewissen Anzahl an (Büro-)Mitarbeitern empfiehlt es sich dagegen über andere Wege nachzudenken, beispielsweise den Arbeitsplatz mit einem (mehr oder weniger) einfachen Telefon auszustatten, ein zentrales Anrufbeantworter-System und einen über Email bedienbaren Fax-Server zu installieren. So eine Lösung skaliert besser und ist effizienter als ein AiO-Gerät überall aufzustellen. Trotzdem werde ich sie nicht für zu Hause vorschlagen oder gar das Heimgerät kategorisch ablehnen.
Angenommen, es gibt eine relativ zentrale Tabelle, die zu Beginn des Projekts nur wenige Spalten und wenige Datensätze enthält. Angenommen, jemand entwirft also eine Abfrage mit "SELECT *", obwohl er nur 3 der Spalten benötigt ... aber "ist ja legitim" (Stichwort "Tippfaulheit").
Tippfaulheit ist für mich kein legitimer Grund. Wenn etwas den aktuellen Erfordernissen genügt, ohne dabei sicherheitsrelvante Probleme mit sich zu bringen, warum sollte man dann mehr Aufwand treiben als nötig? Für Eleganz im Code wird man selten bezahlt. Allerdings kann sich Eleganz beziehungswiese gut wartbarer Code später auszahlen.
Im Laufe dieses Projekts wird diese zentrale Tabelle um mehrere Spalten erweitert und füllt sich mit mehreren zehntausend Datensätzen.
Und irgendwann wird das Statement, das zu Anfang noch legitim war, immer langsamer und la n g s a m ee e e r ... und irgendwann kackt regelmäßig der Server ab.
Und warum? Nur weil ein Entwickler tippfaul war?
Oder unwissend, dass in dem Fall der * die falsche Methode war. Oder die verpasste Gelegenheit, ein vorhandenes Werkzeug zu optimieren, wenn die Ansprüche steigen. Aus dieser Erfahrung kann man lernen, dass für große Datenmengen der * mindestens ungünstig ist und in Richtlinien für große Projekte entsprechende Regeln einbauen. (Am besten begründet, damit die Anwender es nachvollziehen können und nicht nur als Gängelei empfinden.) Aber darf man diese Erfahrung auf jede Situation verallgemeinern?
Sorry, aber IMHO ist "SELECT *" NIEMALS legitim. Die Erfahrung habe ich nun schon in mehreren Projekten gemacht.
Da ist es aber wieder, das kategorische Ablehnen (noch dazu mit Großbuchstaben), nur weil man in bestimmten Situationen damit schlecht gefahren ist. In den meisten Fälle, in denen ich eine Ablehnung beobachte handelt es sich um Wald- und Wiesenscripte, bei denen es nicht darauf ankommt.
Man weiß nie, wie sich eine Tabelle in Zukunft entwickeln wird und man sollte sich genau deshalb nie darauf verlassen, dass es bei der jetzigen Anzahl an Spalten und Datensätzen bleiben wird.
Ja, prinzipeill gesehen mag das für eine Anzahl von Aufgabenstellungen zutreffen, für beispielsweise ein Gästebuch einer privaten Website wird das sicher nicht eintreten und da halte ich es für übertrieben, ein SELECT * zu verteufeln.
echo "$verabschiedung $name";