hilfe habe SQL problem

[dedlfix]

Hi!

Ich habe mir erst darüber Gedanken gemacht, dass select * in den seltesten Fällen die richtige Wahl ist, als ich so eine Kritik wie von EKKI in Foren gelesen habe.

Schau mal nach "nebenan", da gibt EKKi zu, dass er SELECT * täglich verwedet. Also kann es wohl mit dem "seltenst" wohl doch nicht ganz stimmen. Er hat also mit genügend Fällen zu tun, wo er es einsetzt. Ist seine Argumentation dann nicht doch ein wenig widersprüchlich zu seinen Handlungen.

Ich hatte davor oft eine Fehlermeldung wegen doppelter Feldnamen oder auch mir davor kaum Gedanken um die Menge übertragenen Daten gemacht.

Daran ist aber nicht SELECT * schuld sondern deine anfängliche Ignoranz dem Thema gegenüber. Diese anfängliche Ignoranz ist ja auch verständlich, das geht wohl den meisten Anfängern so, dass sie sich erstmal auf das Funktionieren konzentrieren und den Blick für das große Ganze und Zusammenhänge noch nicht kennen. Diese Wissenslücken zu füllen sollte man anregen, ohne Frage, aber bitte nicht durch (einseitige) Thesen/Regeln. Mir ging das in jungen Jahren ja auch so, heute versuche ich die Nebensächlichkeiten am Weg auch gleich mitzunehmen.

Erst durch diese Hinweise habe ich mich überhaupt damit beschäftigt. Vorher hab ich auch überall select * geschrieben.

Hast du das dann auch zum Anlass genommen, das was vorher schief lief zu analysieren, so dass du aus den Fehlern gelernt hast und nicht einfach nur zufälligerweise durch die in manchen Fällen einfach nur umständlichere Notation der einzelnen Felder ein paar Fehler weniger machst, aber nicht genau weißt warum das so ist?

Wie gesagt, Einzelnotation schützt nicht immer, wie im Falle der MySQL-Group-By-Falle zu sehen ist. Ebensowenig garantiert Einzelnotation, dass du daran denkst, nicht mehr benötigte Felder aus einer Abfrage zu entfernen. Die Entlastung der Sorgfaltspflichten beim Umgestalten von Code ist nicht so hoch, wie gern argumentiert wird.

Aber vielleicht liegt der Unterschied auch in der unterscheidlichen Umgebungen begründet. Ich kann mir vorstellen, dass wenn ich eine Desktopanwendung entwickle, mich dieser overhead kaum stören würde. Im gegensatz dazu ist es im Rahmen einer Webanwendung, wo sich jedes Byte Millionenfach potenzieren kann, etwas anderes.

Millionenfach? Na so viele Besucher hat der typische SELECT-*-nicht-darüber-nachgedacht-Anwender nun auch wieder nicht. Wenn eine vielbesuchte Site nicht optimiert, ist sie selbst schuld. Ob die Vermeidung von SELECT * zu einer wesentlichen Einsparung führt muss im Einzelfall geklärt werden. Durch die Einzelnotation werden andererseits auch die Statements länger. Hier kann man sogar mit SELECT * noch zusätzlich ein paar Bytes sparen. Man erstelle sich exakt angepasste Views, was die Feldauflistung angeht, und muss sie so nicht bei jeder Query erneut in voller Länge übertragen, stattdessen nur den *.

Dewegen plädiere ich für Einzelfallbetrachtungen und Hintergrundwissenerwerb statt Thesen und schneller Verallgemeinerungen.
Diese Haltung finde ich ein bisschen übertrieben. Da es so kaum möglich wäre nützliche Tipps zu geben ohne gleichzeitig jedesmal ausufernde Erklärungen abzuliefern, da man ja ansonsten verallgemeinern würde.

Wenn ein Tipp so viele Nebenwirkungen haben kann, dass ihre Erklärung ausufert, würde ich ihn ungern noch als solchen bezeichnen. "Verwende UTF-8" hört sich nach einem einfachen Tipp an, zieht aber nicht selten eine ganze Latte an zu erlernendem Wissen nach sich. Ein Verweis auf Informationsquellen wäre dabei angebracht, und zwar möglichst auf solche, die viele der Fallstricke berücksichtigen und nicht einfach nur ein "du kanns ja googeln, wenn du was zu dem Stichwort wissen willst". Damit findet man ohne Zweifel alle Informationen, weiß aber auch nicht immer, was man alles braucht. Trivialfälle, bei denen man nach dem Lesen der ersten Fundstelle bereits alles erfährt, kann man hingegen problemlos auf Google "abschieben".

Ein bisschen Eigenleistung erwarte ich von den Teilnehmern hier schon. Sodaß sie Aussagen auf ihren Einzelfall herunterbrechen können und gegebenenfalls darüber diskutieren. Dazu ist doch das Forum da.

Trotzdem muss man sie dabei noch oft genug unterstützen, denn wie man richtig herunterbricht und welche Werkzeuge dazu verwendet werden können, muss man häufig genug noch beibringen.

Und solange eine Frage oder Aussage allgemein gehalten wurde, sind allgemeingehaltende Antworten das was ich erwarte. Wenn es dann konkret wird, lassen sich sicher auch Anwendungen für die seltensten Fälle finden oder eben nicht, je nachdem.

Damit sind wir dann bei der anderenorts diskutierten Frage: Welche Antwort darf man auf eine Frage erwarten/geben?

Lo!