nicht angemeldet
echo $begrüßung;
In deinem Posting steckt mit Sicherheit eine Menge Wahrheit drin.
Danke, das hoffe ich doch. Genauso wie ich hoffe, sachlich widerlegt zu bekommen, wenn dem nicht so ist.
Alleine hierin fundieren politische Strukturen, die zu Entscheidungen führen, die auf den ersten Blick wenig sinnvoll erscheinen, so z.B. ablehnende Haltungen gegenüber Stored Procedures für unsere Zwecke.
Achja</maulwurf>, Politik und (In)Kompetenzgerangel tragen nicht gerade zu idealen Bedingungen bei. Wenn die eine Rolle spielen muss man nachsichtig sein und versuchen, das Bestmögliche rauszuholen (oder aber dagegen ankämpfen, wenn es einem der Aufwand und die Aufregung wert ist).
SELECT * hingegen lehne ich in einer Produktionsumgebung vehement ab.
Das ist mir im Prinzip zu dogmentiert.
[...] Wenn wir uns nun darauf verlassen, JOINs und anschließende Gruppierungen auf einem SELECT * aufzubauen, können wir mit 100% Wahrscheinlichkeit davon ausgehen, dass wir Nachbesserungen vornehmen müssen. Können wir hingegen die selektierten Spalten benennen, so ist die Wahrscheinlichkeit deutlich geringer.
Das hingegen ist ein nachvollziehbares Argument, SELECT * nicht einzusetzen. Aufgrund dessen (plus weiterer (sinnbehafteter) Argumente) kann man meinetwegen gern als (projektspezifischen) Standard festlegen, Spaltennamen explizit anzuführen. Wenn es allerdings im Laufe der Zeit nur noch Dogma geworden ist, dann wird es immer weniger nachvollziehbar und findet in mir keinen Fürsprecher.
- Der SQL-Standard sieht IMHO die MySQL-Variante NICHT vor. Wieso pochen wir bei HTML so darauf den Standards des W3C zu folgen, nur damit verlässliche Verarbeitung möglich wird, und sind bei SQL so nachlässig? Ein Standard ist ein Standard, warum darf man hier plötzlich die Standardsyntax benutzen, aber sich abweichend verhalten?
Bei HTML muss eine Quelle von verschiedenen Systemen interpretiert werden. SQL-Statements schneidert man meist dem verwendeten DBMS direkt auf den Leib. Unter anderem deshalb, um die spezifischen Features des DBMS zu nutzen. Der Sinn eines Standards ist eine Austauschbarkeit, doch die ist in den meisten Fällen einfach nicht gefragt. Die Austauschbarkeit bedingt einen teilweise erheblichen Verzicht auf Features, was ich als einen schwerwiegenderen Nachteil ansehe. Wenn beispielsweise als Vorteil der Umstieg auf ein kostengünstigeres System in Betracht kommt, dann haben wir die oben erwähnte Politik im Spiel und technische Argumente schlechte Karten.
Bei einem einfachen JOIN mag der Programmierer überblicken, ob die Auswahl der nicht-gruppierten Spalten eindeutig ist. Was ist, wenn der JOIN komplexer wird? Das DBMS wird keine Warnung rausgeben und sagen "oops, ich glaub da könnte was daneben gehen". Ich ändere ein Statement, ändere ein paar Daten und die Semantik meiner Abfrage ändert sich. Ich persönlich, und ja, ganz offensichtlich darf man hier geteilter Meinung sein, finde das gefährlich.
Potentiell gefährlich ist alles, was man ohne ausreichendes Wissen anwendet. Man kann auch mit register_globals=on unter PHP sichere Scripte programmieren. Nicht das Feature ist das Böse sondern der unachtsame Umgang damit. Wenn es ein "gefährliches" Feature nicht gibt, finden Unachtsame garantiert andere Wege, sich selbst ins Knie zu schießen. Wissen um die Wirkungsweise und verantwortungsvoller Umgang (wobei auch ein Nichtbenutzen eine Option sein kann) ist für mich das Ideal.
echo "$verabschiedung $name";