hilfe habe SQL problem

[bobi]

also ich hätte gerene einen skript mit dem ich aus der Tabelle vip_users in der spalte user_name denn Ihnhalt aus der Tabelle vipforum_users aus der Spalte username anzeigen kann. Beide Tabellen sind in der gleiche SQL Datai .
dddddddddaaaaaaaaaaaaaaaaannnnnnnnke

[EKKi]

Mahlzeit bobi,

also ich hätte gerene einen skript

Das glaube ich nicht - vermutlich reicht eine einfache SQL-Abfrage.

mit dem ich aus der Tabelle vip_users in der spalte user_name denn Ihnhalt aus der Tabelle vipforum_users aus der Spalte username anzeigen kann.

Du solltest vielleicht die genaue Struktur der Tabellen samt ein paar Beispieldaten sowie die genau gewünschte Ergebnismenge zeigen, damit man Dir helfen kann ...

Beide Tabellen sind in der gleiche SQL Datai .

Aha. Welches Datenbanksystem Du verwendest, hast Du aber - trotz entsprechendem Hinweis - bisher verschwiegen. Möchtest Du wirklich, dass Deine Leser raten? Oder willst Du, dass sie Dir helfen?

MfG,
EKKi

[ingobar]

mit dem ich aus der Tabelle vip_users in der spalte user_name denn Ihnhalt aus der Tabelle vipforum_users aus der Spalte username anzeigen kann.

Irgendwie so etwas:

select *
from vip_users, vipforum_users
where vip_users.user_name=vipforum_users.username

Viel Spaß weiter,

ingobar

[EKKi]

Mahlzeit ingobar,

Irgendwie so etwas:

Aber wirklich nur irgendwie.

select *

"SELECT *" ist selten eine gute Idee. Zum einen belastet man die Datenbank damit, *alle* Spalten herauszusuchen und zu übertragen, obwohl man in den seltensten Fällen wirklich alle braucht, zum anderen hat man mit "SELECT *" spätestens dann Spaß, wenn man Gruppierungs- und Aggregatsfunktionen benutzen will ...

Es ist fast immer sinnvoller, nur die Spalten abzufragen, die man auch wirklich haben will.

from vip_users, vipforum_users

Implizite JOINs sind ebensowenig eine gute Idee. Sie erschweren die Lesbarkeit und ...

where vip_users.user_name=vipforum_users.username

... müllen die WHERE-Klausel mit Bedingungen voll, die dort eigentlich nichts zu suchen haben (weil sie eher zur Verknüpfung gehören).

BTW: wieso antwortest Du *mir*?

MfG,
EKKi

[ingobar]

Hallo Ekki,

"SELECT *" ist selten eine gute Idee. Zum einen belastet man die Datenbank damit, *alle* Spalten herauszusuchen und zu übertragen, obwohl man in den seltensten Fällen wirklich alle braucht, zum anderen hat man mit "SELECT *" spätestens dann Spaß, wenn man Gruppierungs- und Aggregatsfunktionen benutzen will ...

Er hatte doch gar nicht gesagt, was er will, oder?

Implizite JOINs sind ebensowenig eine gute Idee. Sie erschweren die Lesbarkeit und ...

Was würdest du empfehlen? Bei mir genügt das immer.

where vip_users.user_name=vipforum_users.username

... müllen die WHERE-Klausel mit Bedingungen voll, die dort eigentlich nichts zu suchen haben (weil sie eher zur Verknüpfung gehören).

Wie willst du das sonst lösen?

BTW: wieso antwortest Du *mir*?

Ich wollte einfach die Diskussion weiterführen. Ich selbst finde es immer ein bisschen schwierig, wenn die Anworten sich über mehrere Pfade aufspalten, da das das durchklicken im Nachhinein erschwert.

ingobar

[EKKi]

Mahlzeit ingobar,

"SELECT *" ist selten eine gute Idee. Zum einen belastet man die Datenbank damit, *alle* Spalten herauszusuchen und zu übertragen, obwohl man in den seltensten Fällen wirklich alle braucht, zum anderen hat man mit "SELECT *" spätestens dann Spaß, wenn man Gruppierungs- und Aggregatsfunktionen benutzen will ...

Er hatte doch gar nicht gesagt, was er will, oder?

Richtig, das hatte er nicht. Deswegen war ich auch nicht so vermessen, ihm eine Abfrage vorzuschlagen, die vielleicht gar nicht seine Anforderungen erfüllt.

Was aber hat das damit zu tun, dass "SELECT *" selten eine gute Idee ist?

Implizite JOINs sind ebensowenig eine gute Idee. Sie erschweren die Lesbarkeit und ...

Was würdest du empfehlen? Bei mir genügt das immer.

Als Alternative? Explizite JOINs natürlich. Im Falle Deines Beispiels würde das dann ungefähr so aussehen:

SELECT vu.foo  
,      vu.bar  
,      vfu.baz  
,      vfu.quz  
  FROM vip_users      AS vu  
  JOIN vipforum_users AS vfu ON vu.user_name = vfu.username

So ist klar erkennbar, welche Tabellen wie über welche Spalten verknüpft werden ... und die WHERE-Klausel dient einzig und allein der Einschränkung der Datenmenge. In meinen Augen ist das erheblich übersichtlicher.

Als Lektüre dazu würde ich Dir "Einführung in Joins" empfehlen.

Wie willst du das sonst lösen?

s.o.

BTW: wieso antwortest Du *mir*?

Ich wollte einfach die Diskussion weiterführen. Ich selbst finde es immer ein bisschen schwierig, wenn die Anworten sich über mehrere Pfade aufspalten, da das das durchklicken im Nachhinein erschwert.

Dies hier ist ein Forum, kein Board. Aus jedem Beitrag können sich theoretisch mehrere einzelne Diskussionsfäden ergeben - und das ist auch sinnvoll und so gewollt: in jedem dieser Stränge werden evtl. ganz unterschiedliche Aspekte behandelt. Es ist daher keine gute Idee, mit seinem eigenen Beitrag einfach auf den letzten/neuesten Beitrag zu antworten und darin dann aber auf einen oder diverse andere Beiträge Bezug zu nehmen.

MfG,
EKKi

[dedlfix]

Hi!

select *
"SELECT *" ist selten eine gute Idee.

Bauchgefühl oder statistische Erhebung?

Zum einen belastet man die Datenbank damit, *alle* Spalten herauszusuchen und zu übertragen,

Solange man nicht überdurchschnittlich große Datenmengen pro Zeile speichert oder ein hochbelastetes System betreibt, ist das mit der heutigen Rechenpower kein Problem mehr, die paar überflüssige Bytes zu transportieren. Eigentlich eigenartig: bei SELECT * erregt es deutlich öfter (empirische Beobachtung) das Spargewissen als beispielsweise bei den vielen ungenutzt übertragenen HTTP-Header-Informationen.

obwohl man in den seltensten Fällen wirklich alle braucht,

Superlativst ausgedrückt. Wenn man bestimmte Information "seltenst" benötigt, warum belastet man dann das DBMS mit ihrer Speicherung. Und wäre ein SELECT * immer noch verteufelnswert, wenn man das auf eine genau für den gewünschten Anwendungsfall zugeschnittene View anwendet?

zum anderen hat man mit "SELECT *" spätestens dann Spaß, wenn man Gruppierungs- und Aggregatsfunktionen benutzen will ...

Syntax, die in bestimmten Fällen unpassend ist, rechtfertigt noch lange nicht eine generelle Ablehnung.

Es ist fast immer sinnvoller, nur die Spalten abzufragen, die man auch wirklich haben will.

Sinnvoll in wessen Sinne? Eine pauschale Sinnhaftigkeit für alle Anwendungsfälle kann es nicht geben.

Implizite JOINs sind ebensowenig eine gute Idee. Sie erschweren die Lesbarkeit und ...
... müllen die WHERE-Klausel mit Bedingungen voll, die dort eigentlich nichts zu suchen haben (weil sie eher zur Verknüpfung gehören).

Ich kann mich noch erinnern, dass ich mich auch etwas schwer getan hatte, die implizite Schreibweise zu verlassen. Ich denke aber nicht, dass es sehr beim Überzeugen hilft, wenn man statt mit den Vorteilen eines besseren Systems Werbung zu machen ein anderes herabwürdigt. Das weckt doch eher den Beschützerinstinkt. In einem Folgeposting zeigst du ja, wie die explizite Schreibweise ausieht. Das sollte eine bessere Argumentationsweise sein. Auch dass man sie für andere Join-Arten als den INNER JOIN benötigt (Oracle nicht betrachtet), und sie sowieso kennenlernen muss, wäre ein positives Argument, sich mit ihr zu beschääftigen.

Lo!

[EKKi]

Mahlzeit dedlfix,

select *
"SELECT *" ist selten eine gute Idee.

Bauchgefühl oder statistische Erhebung?

Erfahrung.

Zum einen belastet man die Datenbank damit, *alle* Spalten herauszusuchen und zu übertragen,

Solange man nicht überdurchschnittlich große Datenmengen pro Zeile speichert oder ein hochbelastetes System betreibt, ist das mit der heutigen Rechenpower kein Problem mehr, die paar überflüssige Bytes zu transportieren.

Es ist bei verschiedensten Projekten, an denen ich mitgearbeitet habe, schon häufiger zu Performance-Problemen gekommen, weil an irgendeiner ganz unbedeutend erscheinenden Stelle irgendwer irgendwann mal ein unscheinbares "SELECT * FROM kundendaten WHERE [...]" hineingefrickelt hat (Weil's ja schnell gehen musste und so!) ... und irgendwann, wenn dann die Kundendaten Dimensionen annehmen, die bei der Konzeption nicht genügend bedacht wurden und dieses kleine Statement an verschiedenen Stellen aufgerufen ständig ausgeführt wird, geht auch das leistungsfähigste System in die Knie.

Natürlich wäre das mit einem skalierbaren Datenbankdesign und bedachter Programmierung alles kein Problem ... aber - mal Hand auf's Herz: wo klappt das schon *IMMER* zu 100%? Irgendwas ist immer: Zeitdruck, nachträgliche Änderungen (Die total wichtig sind!!!111einsELF), paralleles Arbeiten durch unterschiedliche, teils wechselnde Kollegen usw. - alles schon erlebt.

obwohl man in den seltensten Fällen wirklich alle braucht,

Superlativst ausgedrückt. Wenn man bestimmte Information "seltenst" benötigt, warum belastet man dann das DBMS mit ihrer Speicherung.

Es gibt durchaus Daten, die man z.B. im Frontend kaum benötigt, im Backend aber schon. Mir fallen da spontan die IP-Adresse des Erstellers eines Datensatzes, der Zeitstempel des Erstellens usw. ein. Die muss ich nicht jedesmal für jeden einzelnen Datensatz vom Datenbankserver zum Webserver übertragen, wenn ich sie eh nicht benötige.

Und wäre ein SELECT * immer noch verteufelnswert, wenn man das auf eine genau für den gewünschten Anwendungsfall zugeschnittene View anwendet?

Nein. Deswegen habe ich auch nicht geschrieben "'SELECT *' ist generell und immer Scheiße!", sondern "'SELECT *' ist selten eine gute Idee."

Wie neulich jemand bemerkte: "SELECT *" kann das richtige Werkzeug sein - wenn man weiß, was man tut. Wenn man das nicht weiß, ist es unwahrscheinlich, dass man "SELECT *" benutzen möchte oder es gar benutzen *muss*.

zum anderen hat man mit "SELECT *" spätestens dann Spaß, wenn man Gruppierungs- und Aggregatsfunktionen benutzen will ...

Syntax, die in bestimmten Fällen unpassend ist, rechtfertigt noch lange nicht eine generelle Ablehnung.

Habe ich das getan? Nein. Was also soll Dein agressiver Unterton (sofern man bei schriftlicher Kommunikation von "Tönen" sprechen kann)?

Es ist fast immer sinnvoller, nur die Spalten abzufragen, die man auch wirklich haben will.

Sinnvoll in wessen Sinne? Eine pauschale Sinnhaftigkeit für alle Anwendungsfälle kann es nicht geben.

Nochmal: was willst Du mit diesem Beitrag und diesen Formulierungen bewirken? Willst Du mich produzieren?

MfG,
EKKi

[dedlfix]

Hi!

Nochmal: was willst Du mit diesem Beitrag und diesen Formulierungen bewirken? Willst Du mich produzieren?

Ich möchte einfach nur, dass oft zu lesende Thesen wie "XY ist Mist" weniger unbegründet/unerklärt auftauchen und dass stattdessen möglichst fundierte Informationen über die (möglichst nicht vorverurteilten) Eigenschaften von Dingen und deren Alternativen gegeben werden. Das muss man ja nicht ständig und immer wieder aufs neue formulieren, sondern kann auch vorhandene Beiträge, Webseiten usw. verlinken. Entsprechende Artikel im SELFHTML-Wiki zu verfassen, böte sich da auch an.

Lo!

[Struppi]

Nochmal: was willst Du mit diesem Beitrag und diesen Formulierungen bewirken? Willst Du mich produzieren?

Ich möchte einfach nur, dass oft zu lesende Thesen wie "XY ist Mist" weniger unbegründet/unerklärt auftauchen ...

Hat das EKKI hier wirklich gemacht?
Weder hat er eine abfällige Bezeichnung gewählt, noch war seine Aussage unbegründet. Im gegenteil er hat relativiert und zwei Argumente genannt.

Insofern kann ich auch nicht deinen Vorwurf nachvollziehen.

Struppi.

[dedlfix]

Hi!

Nochmal: was willst Du mit diesem Beitrag und diesen Formulierungen bewirken? Willst Du mich produzieren?
Ich möchte einfach nur, dass oft zu lesende Thesen wie "XY ist Mist" weniger unbegründet/unerklärt auftauchen ...
Hat das EKKI hier wirklich gemacht?

Zumindest die Begründung war mir nicht stichhaltig und vor allem nicht neutral/ausgewogen genug.

Weder hat er eine abfällige Bezeichnung gewählt, noch war seine Aussage unbegründet. Im gegenteil er hat relativiert und zwei Argumente genannt.

Und die hab ich ihm auch zu widerlegen versucht.

Insofern kann ich auch nicht deinen Vorwurf nachvollziehen.

Es war an dieser Stelle nur noch eine Aussage allgemeiner Art, kein Vorwurf. Der eigentliche Vorwurf kam schon eher und bezog sich auf die Einseitigkeit und unnötige Extremisierung seiner Argumentation.

Lo!

[Struppi]

Nochmal: was willst Du mit diesem Beitrag und diesen Formulierungen bewirken? Willst Du mich produzieren?
Ich möchte einfach nur, dass oft zu lesende Thesen wie "XY ist Mist" weniger unbegründet/unerklärt auftauchen ...
Hat das EKKI hier wirklich gemacht?

Zumindest die Begründung war mir nicht stichhaltig und vor allem nicht neutral/ausgewogen genug.

Das leuchtet mir wirklich nicht ein.

Wenn er sagt, dass man in den seltesten Fällen alle Felder braucht, ist das nicht ausgewogen und neutral?

Und das man bei Aggregatsfunktionen "Spaß" hat, ist vielleicht nicht stichhaltig, aber als Hinweis durchaus sinnvoll, da keiner weiß wie der OP diese Funktion nutzt.

Weder hat er eine abfällige Bezeichnung gewählt, noch war seine Aussage unbegründet. Im gegenteil er hat relativiert und zwei Argumente genannt.

Und die hab ich ihm auch zu widerlegen versucht.

OK, ein Threaddrift.
Aber entnehme ich dem, dass du dazu rätst allgemein ein SELECT * zu verwenden, weil nichts dagegen spricht?

Ausserdem sprichst du in deiner Antwort ständig von Verteufelung, obwohl EKKI genau das nicht getan hat.

Ich bin ja auch kein DB Profi, aber ich empfand den Hinweis von EKKI hilfreich und nachvollziehbar, weil in fast jeder Tabelle Felder stecken, die nicht bei jeder Abbfrage nötig sind und gerade bei joins sind das dann mehrere, die oft auch noch die gleichen Namen tragen (wie z.b. das last_change oder is_deleted).

Das das (heutzutage) nicht unbedingt der Performancekiller ist, ist klar, diese sollte man sich über EXPLAIN o.ä. suchen, aber es war ja auch keine Performancefrage.

Mich hat eher dein Einwurf verwirrt, weil ich dich als DB Fachmann kenne, aber ich konnte deine Einwände nicht nachvollziehen. Da deine Argumentation:

Wenn man bestimmte Information "seltenst" benötigt, warum belastet man dann das DBMS mit ihrer Speicherung..

Das entspricht zumindest bei mir in den seltesten Fällen der Realität, natürlich sind in den Tabellen Informationen die nur für bestimmte Dinge nötig sind und seltenst beim Client benötigt werden.

Insofern kann ich auch nicht deinen Vorwurf nachvollziehen.

Es war an dieser Stelle nur noch eine Aussage allgemeiner Art, kein Vorwurf. Der eigentliche Vorwurf kam schon eher und bezog sich auf die Einseitigkeit und unnötige Extremisierung seiner Argumentation.

Nochmal: genau das hat er nicht getan. Die Argumentation war weder einseitig noch extrem, im gegenteil.

Struppi.

[dedlfix]

Hi!

Zumindest die Begründung war mir nicht stichhaltig und vor allem nicht neutral/ausgewogen genug.
Das leuchtet mir wirklich nicht ein.

Nun, dann muss ich vermutlich meine Fähigkeiten im Rüberbringen der Gegenargumente verbessern. Ich habe in seinen Aussagen eine deutlich ablehnende Argumentation herausgelesen.

Wenn er sagt, dass man in den seltesten Fällen alle Felder braucht, ist das nicht ausgewogen und neutral?

Ist es nicht, weil ich es so extremisiert nicht als richtig erachte. "Seltenst" wäre für mich irgendwo bei 99%. Vielleicht sind meine Datenmodelle auch besser angelegt, so dass ich auch bei einem SELECT * nicht viel überflüssiges bekomme.

Und das man bei Aggregatsfunktionen "Spaß" hat, ist vielleicht nicht stichhaltig, aber als Hinweis durchaus sinnvoll, da keiner weiß wie der OP diese Funktion nutzt.

Bei SQL-DBMSen außer MySQL kann man bei Gruppierungen nur die gruppierten Felder direkt verwenden. Andere anzugeben erzeugt eine Fehlermeldung. Bei MySQL kann man alle Felder unabhängig von einer Gruppierung wählen. Eine separate Aufzählung von Feldnamen verhindert die damit verbundene Problematik nicht, weswegen eine SELECT-*-Vermeidung in dem Fall nicht automatisch zum Problemlöser wird. (Ein Problem ist das auch nur, wenn man sich der Auswirkungen nicht bewusst ist.)

Und ich behaupte mal: Ein SELECT * verursacht mehr Diskussionen als wirkliche Probleme.

Aber entnehme ich dem, dass du dazu rätst allgemein ein SELECT * zu verwenden, weil nichts dagegen spricht?

Nein. Ich rate dazu, anwendungsfallabhängig über eine Verwendung von bestimmten Dingen zu entscheiden. Dazu muss man die Auswirkungen kennen und nicht nur irgendwelche verallgemeinerten Thesen, die man noch dazu nicht hinterfragt hat. Nur so kann man Vorteile und Nachteile für eben diesen Fall optimal einschätzen.

Ausserdem sprichst du in deiner Antwort ständig von Verteufelung, obwohl EKKI genau das nicht getan hat.

Wie gesagt, entnahm ich eine ablehnende Grundstimmung. Und da Ablehnungen auch anderswo zu häufig und oftmals unbegründet zu lesen sind, war ich hier möglicherweise etwas ungerecht ihm gegenüber. Es geht mir aber nicht nur speziell um ihn, sondern ich hoffe, dass weitere Mitleser sich mit der Sache beschäftigen und ihre gelernten Thesen darüber überdenken.

Ich bin ja auch kein DB Profi, aber ich empfand den Hinweis von EKKI hilfreich und nachvollziehbar, weil in fast jeder Tabelle Felder stecken, die nicht bei jeder Abbfrage nötig sind und gerade bei joins sind das dann mehrere, die oft auch noch die gleichen Namen tragen (wie z.b. das last_change oder is_deleted).

"In fast jeder Tabelle" ist auch so eine allgemeine und schwer zu be- und widerlegende Annahme. Irgendwelche Thesen und Annahmen allgemeiner Art entbinden meiner Meinung nach jedenfalls nicht von einer individuellen Betrachtung jedes Einzelfalls, wenn man optimale Ergebnisse auf effiziente Weise bekommen möchte.

Das das (heutzutage) nicht unbedingt der Performancekiller ist, ist klar, diese sollte man sich über EXPLAIN o.ä. suchen, aber es war ja auch keine Performancefrage.

Ja, es war keine Performancefrage (im OP), weswegen man eigentlich auch nicht mit Performance-Erwägungen argumentieren muss. Er hat jedoch die Belastung des Servers angesprochen und ich bin darauf eingegangen.

Mich hat eher dein Einwurf verwirrt, weil ich dich als DB Fachmann kenne, aber ich konnte deine Einwände nicht nachvollziehen. Da deine Argumentation:

Wenn man bestimmte Information "seltenst" benötigt, warum belastet man dann das DBMS mit ihrer Speicherung..
Das entspricht zumindest bei mir in den seltesten Fällen der Realität, natürlich sind in den Tabellen Informationen die nur für bestimmte Dinge nötig sind und seltenst beim Client benötigt werden.

Ich bin auf die meiner Meinung nach nicht gerechtfertigte, weil nicht belegbare Verwendung des Superlativs angesprungen. Solche Annahmen führen gern zu einer Regel, die einem das Nachdenken über individuelle Fälle ersparen soll. Die Anwendung solcher Regeln führt aber nicht zwangsläufig zu einem optimalen Ergebnis, weil sie nicht unbedingt den speziell vorliegenden Fall optimal berücksichtigt hat.

Insofern kann ich auch nicht deinen Vorwurf nachvollziehen.
Es war an dieser Stelle nur noch eine Aussage allgemeiner Art, kein Vorwurf. Der eigentliche Vorwurf kam schon eher und bezog sich auf die Einseitigkeit und unnötige Extremisierung seiner Argumentation.
Nochmal: genau das hat er nicht getan. Die Argumentation war weder einseitig noch extrem, im gegenteil.

Der Meinung war ich nicht. "Seltenst" ist für mich ein Extrem. Und er hat keine Argeumente für SELECT * gebracht, was dann für mich einseitig genug ist. Zugegeben, so viele kenne ich nicht. Das einzige Argument für SELECT *, das mir einfällt, ist, es genau dann anzuwenden, wenn man seine Funktionalität benötigt. Es werden aber viele Argumente dagegen genannt, die in ihrer Pauschalität nicht immer dem konkreten Fall angemessen sind. Dewegen plädiere ich für Einzelfallbetrachtungen und Hintergrundwissenerwerb statt Thesen und schneller Verallgemeinerungen.

Lo!

[Struppi]

Wenn er sagt, dass man in den seltesten Fällen alle Felder braucht, ist das nicht ausgewogen und neutral?

Ist es nicht, weil ich es so extremisiert nicht als richtig erachte. "Seltenst" wäre für mich irgendwo bei 99%. Vielleicht sind meine Datenmodelle auch besser angelegt, so dass ich auch bei einem SELECT * nicht viel überflüssiges bekomme.

Ja, das mag sein. Die meisten Abfragen, die ich verwende sind joins über mehrere Tabellen, es werden dort in der Regel aber nur eine Handvoll Felder davon benötigt und eigentlich nie alle aller Tabellen.

... (Ein Problem ist das auch nur, wenn man sich der Auswirkungen nicht bewusst ist.)

Naja, dann war doch EKKI Hinweis, dass du damit alle Felder aller Tabellen selektierst, die unter Umständen gar nicht gebraucht werden, doch ein sehr guter Hinweis.

Ich rate dazu, anwendungsfallabhängig über eine Verwendung von bestimmten » Es geht mir aber nicht nur speziell um ihn, sondern ich hoffe, dass weitere Mitleser sich mit der Sache beschäftigen und ihre gelernten Thesen darüber überdenken.

Genau das verwirrte mich. 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. Ich hatte davor oft eine Fehlermeldung wegen doppelter Feldnamen oder auch mir davor kaum Gedanken um die Menge übertragenen Daten gemacht.

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

Ich bin ja auch kein DB Profi, aber ich empfand den Hinweis von EKKI hilfreich und nachvollziehbar, weil in fast jeder Tabelle Felder stecken, die nicht bei jeder Abbfrage nötig sind und gerade bei joins sind das dann mehrere, die oft auch noch die gleichen Namen tragen (wie z.b. das last_change oder is_deleted).

"In fast jeder Tabelle" ist auch so eine allgemeine und schwer zu be- und widerlegende Annahme. Irgendwelche Thesen und Annahmen allgemeiner Art entbinden meiner Meinung nach jedenfalls nicht von einer individuellen Betrachtung jedes Einzelfalls, wenn man optimale Ergebnisse auf effiziente Weise bekommen möchte.

Naja, ich behaupte mal, dass jede Tabelle, die nicht der Verknüpfung dient immer eine gewisse Redundanz enthält, die sich durch joins nochmal potenzieren kann. Das ist doch allein schon dadurch gegeben, dass jedes Feld für spezielle Funktionen gedacht ist. Es gibt Felder die dienen der Beschreibung des Datensatzinhalt, der Verknüpfung mit anderen Tabellen oder die lediglich zusätzliche (Debug)Informationen enthalten. Und es gibt wahrscheinlich noch mehr Möglichkeiten.

Insofern halte ich die Quantifizierung "seltenst" für eine nicht übertrieben grosse Einheit, sondern entspricht dem, was auch zumindest bei mir üblicherweise anfällt.

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.

Der Meinung war ich nicht. "Seltenst" ist für mich ein Extrem. Und er hat keine Argeumente für SELECT * gebracht, was dann für mich einseitig genug ist. Zugegeben, so viele kenne ich nicht. Das einzige Argument für SELECT *, das mir einfällt, ist, es genau dann anzuwenden, wenn man seine Funktionalität benötigt. Es werden aber viele Argumente dagegen genannt, die in ihrer Pauschalität nicht immer dem konkreten Fall angemessen sind. 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. 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.

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.

Struppi.

[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!

[EKKi]

Mahlzeit dedlfix,

Schau mal nach "nebenan", da gibt EKKi zu, dass er SELECT * täglich verwedet.

Ich nehme auch für mich in Anspruch, dass ich ansatzweise weiß, was ich der Datenbank da zumute. Außerdem setze ich "SELECT *" mit Bedacht nur zu speziellen Zwecken und in bestimmten Situationen ein (das hatte ich "nebenan" auch geschrieben).

Bei Anfängern ist beides häufig eben *nicht* der Fall, weshalb man sie für die Probleme, die "SELECT *" machen *kann*, sensibilisieren sollte.

Also kann es wohl mit dem "seltenst" wohl doch nicht ganz stimmen.

Doch - wie ich "nebenan" auch schrieb: ich nutze "SELECT *" fast *ausschließlich* für Ad-Hoc-Abfragen und zur Entwicklung auf unseren Entwicklungs- und Test-Systemen. Die produktiven Datenbanken werden durch unsere Skripte AFAIK an keiner einzigen Stelle mit einem "SELECT *" direkt auf Tabellen (wohlmöglich noch kreuz-und-quer-geJOINt), sondern höchstens auf speziell dafür existierende Views (die nur die wirklich benötigten Spalten enthalten und bei denen dann keine weiteren JOINs mehr nötig sind) befüttert.

IMHO ist das "seltenst".

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.

Nein, ist sie nicht.

MfG,
EKKi

[Struppi]

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 hab das gelesen, es handelt sich genau um _einen_ Fall, dann wenn er eine AdHoc Abfrage macht. Ich tippe in phpmyadmin auch nicht jedesmal alle Felder ein, deren Werte ich Wissen will.

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.

Da finde ich dich jetzt widersprüchlich. Wenn er sagt "in den seltesten Fällen" ist das in dem Fall vielleicht noch mal der Nachdruck sich darüber Gedanken zu machen ob es hier wirklich gebraucht wird. Also ob sein konkreter Fall einer der selten Fälle ist. Und wenn er die Wissenslücke schliessen will kann er nachfragen, z.b. in welchen Fällen es sinnvoll sein kann alle Felder zu selektieren.

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?

Keine Ahnung was du jetzt damit meinst, ich habe das gemacht um die Menge der Daten, die durch automatische Prozesse auch immer in die Anwendung einfliessen, geringer zu machen. Da ist die Analyse nicht so aufwendig um zu erkennen, dass wenn ich nur fünf statt fünfzehn Felder habe der Aufwand deutlich geringer ist.

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.

Es geht nicht um Besucher, aber in der Regel hast du nicht eine Abfrage pro Seitenaufruf sondern viele und selbst geringe Besucherzahlen können, wenn diese unerwartet parallel stattfinden, dann einen Server bzw. in dem Fall fast immer ein einfaches Webhosting Angebot, schnell in die Knie zwingen.

.. 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 *.

Das erfordert dann aber erstmal ein erweitertes Wissen über views und wann diese sinnvoll angewendet werden. Ist also eine Aussage die sich erst nach Nachfrage tätigen läßt.

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".

Das klingt so, als ob du in deinem Wissengebiet immer alles weißt und Internetfundstellen kennst, wo man das entsprechend nachlesen kann.

Ich kann das von mir nicht behaupten, aber mir macht es auf der anderen Seite auch Spaß nach Informationen zu suchen, eben um die verschiedenen Aspekte einer Sache zu erlernen. Aber wenn es nur darum geht, _das_ einzig wahre Richtige zu vermitteln, dann wäre ich am falschen Ort, weil diesen Anspruch habe ich nicht und kann ich auch nicht erfüllen.

Ich mache Fehler und lerne immer noch dazu, kann also nie ausschliessen, dass ich eine, in deinen Augen wohl einseitige und verallgemeinerte Aussage treffe, weil sie meinem aktuellen Wissenstand und Erfahrung entspricht.

Das liegt aber sicher auch daran wie intensiv man sich mit einem Thema beschäftigt und wie und wo man das lernt. Das es darin hier große Unterschiede gibt läßt sich nicht bestreiten und so ist es auch klar, dass die Antworten sehr unterschiedlich ausfallen, aber auch unterschiedlich interpretiert werden.

Während dir und Ilja die Antwort zu flach und zu kurz gegriffen erscheint, ist sie für mich ein wertvoller Hinweis auf eine Problematik, mit der ich mich u.U. noch nicht beschäftigt habe und ich bin dankbar, dass ich ihn bekommen habe (also nicht jetzt, sondern überhaupt).

Das eine verallgemeinerung nie 100% stimmt (die ich in der Aussage auch so gar nicht gesehen hatte), sollte man natürlich Wissen, das ist genau wie mit der Behauptung hier im Forum würden HTML Tabellen gehaßt, was so ja auch nicht stimmt.

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?

Ja, sieht so aus. Aber um das auf den aktuellen Thread zu beziehen, dir wäre es lieber gewesen EKKI hätte gar nichts geschrieben und bobi lebt weiterhin mit der in selfhtml vermittelten Wissen, dass ein select * eine sinnvolle Abfrage ist, die sich allgemein (ingobar hat diesen Vorschlag ja nicht relativiert und damit verallgemeineinert) so einsetzen läßt?

Ich finde erst durch die Antwort von EKKI wurde diese Aussage relativiert und der OP hat die Möglichkeit sich darüber Gedanken zu machen, da er ansonsten vermutlich gar keine andere Information bekommen hätte.

Struppi.

[dedlfix]

Hi!

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".

Das klingt so, als ob du in deinem Wissengebiet immer alles weißt und Internetfundstellen kennst, wo man das entsprechend nachlesen kann.

Ich wollte das Optimum beschreiben, wie ich es mir vorstelle, unabhängig von meinem Wissen oder Nichtwissen. Es sollten zumindest soviel Informationen gegeben werden, dass auch auf wenig bekannte oder nicht offensichtliche Fallstricke Rücksicht genommen wird. Natürlich weiß ich nicht immer alles, will das auch gar nicht und vergesse vieles wieder. Aber ich weiß üblicherweise, wo ich nachlesen beziehungsweise mit der Recherche beginnen kann. - Reihenfolge von Funktionsparametern, konkrete Schreibweise von Funktionsnamen und sowas kann man alles auswendig lernen. Das spar ich mir und schlage nach, wenn ich es brauche, oder die Syntaxvervollständigung der IDE sagt es mir. Wenn es sich im Laufe der Zeit von selbst einprägt, dann ist es auch ok.

Ich kann das von mir nicht behaupten, aber mir macht es auf der anderen Seite auch Spaß nach Informationen zu suchen, eben um die verschiedenen Aspekte einer Sache zu erlernen. Aber wenn es nur darum geht, _das_ einzig wahre Richtige zu vermitteln, dann wäre ich am falschen Ort, weil diesen Anspruch habe ich nicht und kann ich auch nicht erfüllen.

Den hab ich auch nicht, denn das einzig wahre Richtige wäre wieder eine Pauschale, die gar nicht alle Anwendungsfälle angemessen berücksichtigen kann oder andererseits so allgemein formuliert ist, dass sie im Einzelfall allein (ohne fachlich notwendiges Wissen) keine Punkte bringt. Deshalb versuche ich bei nicht bekannten konkreten Umständen eher Eigenschaften statt Vor- und Nachteile zu erklären, weil Vor- und Nachteile situationsabhängig zu bewerten und Eigenschaften anwendungsfallneutral sind.

Ich mache Fehler und lerne immer noch dazu, kann also nie ausschliessen, dass ich eine, in deinen Augen wohl einseitige und verallgemeinerte Aussage treffe, weil sie meinem aktuellen Wissenstand und Erfahrung entspricht.

Das kann ich für mich auch nicht ausschließen, aber ich bemühe mich darum.

Das liegt aber sicher auch daran wie intensiv man sich mit einem Thema beschäftigt und wie und wo man das lernt. Das es darin hier große Unterschiede gibt läßt sich nicht bestreiten und so ist es auch klar, dass die Antworten sehr unterschiedlich ausfallen, aber auch unterschiedlich interpretiert werden.

Während dir und Ilja die Antwort zu flach und zu kurz gegriffen erscheint, ist sie für mich ein wertvoller Hinweis auf eine Problematik, mit der ich mich u.U. noch nicht beschäftigt habe [...]

Ich denke, es ist besser, zum Hinterfragen anzuregen, beispielsweise mit einer anzweifelnden Frage, als mit einer mehr oder weniger wertenden Aussage.

Das eine verallgemeinerung nie 100% stimmt (die ich in der Aussage auch so gar nicht gesehen hatte), sollte man natürlich Wissen, [...]

Und da stellt sich mir dann die Frage, was so eine Verallgemeinerung dann noch wert ist, wenn sie nicht stimmt.

[...] dir wäre es lieber gewesen EKKI hätte gar nichts geschrieben und bobi lebt weiterhin mit der in selfhtml vermittelten Wissen, dass ein select * eine sinnvolle Abfrage ist, die sich allgemein (ingobar hat diesen Vorschlag ja nicht relativiert und damit verallgemeineinert) so einsetzen läßt?

Mir wäre es lieber gewesen, er hätte es neutraler vermittelt, um so dem Anwender bei der Entscheidungsfindung zu helfen, ob die Eigenschaften für seinen Fall, der uns nicht konkret bekannt ist, positiv, negativ oder belanglos sind. EKKi (oder wer auch immer) kann aufgrund seiner Erfahrung ja ruhig anzweifeln, dass SELECT * in dem (oder einem belibigen anderen) Fall wohl nicht optimal ist, aber die Wertung und Entscheidung muss letzlich der Anwender treffen (können).

Ich finde erst durch die Antwort von EKKI wurde diese Aussage relativiert und der OP hat die Möglichkeit sich darüber Gedanken zu machen, da er ansonsten vermutlich gar keine andere Information bekommen hätte.

Wäre vielleicht aber auch nicht gravierend gewesen. Wir wissen es nicht.

Lo!

[Ilja]

moin,

"SELECT *" ist selten eine gute Idee. Zum einen belastet man die Datenbank damit, *alle* Spalten herauszusuchen und zu übertragen, obwohl man in den seltensten Fällen wirklich alle braucht

das problem ist, dass SELECT * einen generalverdacht hervorruft, lange zeit sogar hier im forum grundsätzlich verteufelt wurde. das muss endlich mal aufhören, SELECT * hat seine berechtigung, period. natürlich muss man das jeweilige tool zum richtigen moment anwenden. aber ohne jetzt im detail auf deinen beitrag einzugehen, gebe ich dedlfix recht, es macht keinen sinn immer auf SELECT * zu wettern.

Ilja

[EKKi]

Mahlzeit Ilja,

das problem ist, dass SELECT * einen generalverdacht hervorruft, lange zeit sogar hier im forum grundsätzlich verteufelt wurde. das muss endlich mal aufhören, SELECT * hat seine berechtigung, period.

Wenn man weiß, was man tut und welche Auswirkungen die Benutzung von "SELECT *" hat, ja. Dieses Wissen spreche ich Anfängern (und für so einen halte ich bobi aufgrund der Art der Fragestellung) grundsätzlich ab. Deshalb erwähne ich diesen Umstand (dass "SELECT *" selten eine gute Idee ist - ich *habe* *es* *nicht* *grundsätzlich* *verteufelt*!) in Threads von Anfängern, in denen früher oder später fast immer "SELECT *" auftaucht, gerne. Mittlerweile gebe ich mir ja auch Mühe, in kurzen Sätzen zu begründen, *warum* das so ist und darauf hinzuweisen, dass der Fragesteller sich bitte darüber informieren möge, *warum* das so ist.

aber ohne jetzt im detail auf deinen beitrag einzugehen, gebe ich dedlfix recht, es macht keinen sinn immer auf SELECT * zu wettern.

Ach sooo, Du hast meinen Beitrag gar nicht wirklich gelesen ... na dann ... Gratulation zum Beißreflex - hat funktioniert!

MfG,
EKKi

[Ilja]

moin,

Wenn man weiß, was man tut und welche Auswirkungen die Benutzung von "SELECT *" hat, ja. Dieses Wissen spreche ich Anfängern (und für so einen halte ich bobi aufgrund der Art der Fragestellung) grundsätzlich ab.

das sehe ich grundsätzlich anders, ich bin der meinung, wenn man es gleich richtig vermittelt, dann haben es auch anfänger leichter. SELECT * hat viele gute einsatzmöglichkeiten, adhoc-abfragen, views, etc. und wenn ich bedenke, wie oft ich adhoc abfragen jeden tag benötige, auch bei abfragen mit joins, würde ich mal bestreiten, dass SELECT * wesentlich weniger sinnvoll eingesetzt werden kann.

Deshalb erwähne ich diesen Umstand (dass "SELECT *" selten eine gute Idee ist - ich *habe* *es* *nicht* *grundsätzlich* *verteufelt*!)

das hast du nicht, deswegen schrieb ich ja auch, dass ich mich nicht im detail mit deinem beitrag auseinander setzen will. jedes forum hat auch irgendwie seine eigenheiten, wenn es um die beantwortung von fragen geht. man spielt sich gegenseitig ein und eine art "kollektive meinung" bildet sich. darunter fählt sicherlich das SELECT *, als auch die schnellen aussagen, dass ein Daten-design fehlerhaft ist, ohne die entsprechenden hintergründe zu kennen.

ich denke, was deldfix versucht ist, dass SELECT * ein wenig aus der schmudel-ecke heraus zu bekommen und es als ganz normales werkzeug zu sehen, das täglich seinen einsatz hat. und dabei will ich deldfix unterstützen.

aber ohne jetzt im detail auf deinen beitrag einzugehen, gebe ich dedlfix recht, es macht keinen sinn immer auf SELECT * zu wettern.

Ach sooo, Du hast meinen Beitrag gar nicht wirklich gelesen ... na dann ... Gratulation zum Beißreflex - hat funktioniert!

dann hast du nicht richtig kombiniert, nicht auf etwas eingehen heißt nicht, das ich deinen beitrag nicht gelesen habe. aber du nimmst das alles viel zu persönlich und für mich ist das keine diskussion über einen beitrag von dir, sondern eine diskussion über viele beiträge hinweg, die eben zu solch einer "kollektiven meinung" geführt haben. deswegen sehe ich auch keinen grund, ins detail zu gehen, ob der eine satz nun gut oder weniger gut gewählt wurde. es geht dabei eher um eine grundsätzliche meinung.

Ilja

[EKKi]

Mahlzeit Ilja,

das sehe ich grundsätzlich anders, ich bin der meinung, wenn man es gleich richtig vermittelt, dann haben es auch anfänger leichter.

Richtig. Aber dieses "gleich richtig vermitteln" sollte IMHO nicht in einem Forum, sondern in einem entsprechenden Tutorial o.ä. erfolgen, in dem dann auch eingehend die Vor- und Nachteile der Verwendung von "SELECT *" behandelt werden.

In einem Forum kann man im Prinzip gerade Anfängern, die eben *nicht* um die Schwierigkeiten und Probleme von "SELECT *" wissen, sondern nur die schnelle und einfache Verwendung sehen, nur mitteilen, dass "SELECT *" selten eine gute Idee ist (zumindest, wenn entsprechende Abfragen fest in irgendwelchen Programmcode eingebaut werden - aber dabei geht es doch hier in den meisten Fällen?!) und dass sie sich doch bitte darüber informieren mögen.

SELECT * hat viele gute einsatzmöglichkeiten, adhoc-abfragen, views, etc. und wenn ich bedenke, wie oft ich adhoc abfragen jeden tag benötige, auch bei abfragen mit joins, würde ich mal bestreiten, dass SELECT * wesentlich weniger sinnvoll eingesetzt werden kann.

Sicher, ich benutzte "SELECT *" auch jeden Tag mindestens ein Dutzend mal, um "mal eben schnell" im PL/SQL-Developer in eine Tabelle/View hineinzuschauen oder um komplexere Abfragen zu entwickeln.

In den (späteren Programm-)Code aber übernehme ich "SELECT *" aus Prinzip fast niemals - ganz einfach weil ich nicht weiß, ob sich nicht irgendwann in der Zukunft an den Datenstrukturen noch etwas ändert, ob irgendwann jemand meine Abfragen erweitert oder umbaut usw.

ich denke, was deldfix versucht ist, dass SELECT * ein wenig aus der schmudel-ecke heraus zu bekommen und es als ganz normales werkzeug zu sehen, das täglich seinen einsatz hat. und dabei will ich deldfix unterstützen.

In einer Schmuddelecke hat es ja auch nichts zu suchen - es ist nur ein Werkzeug, das im produktiven Einsatz mit Bedacht gewählt werden sollte.

Wie oft hatten wir hier schon Anfänger, die mit mehr oder weniger hilfreichen Problembeschreibungen ihrer Verzweiflung Luft machten, weil "die Datenbank nicht funzt" - und letztendlich stellte sich dabei oft genug heraus, dass sie ein "SELECT *" auf relativ komplexe Konstruktionen losgelassen haben, und ...

a) ... MySQL trotz Aggregatsfunktionen nicht gemeckert hat, aber einfach *irgendwas* zurückgeliefert hat und nicht die erhofften Daten,

b) ... es Probleme mit (impliziten) JOINs (ohne Tabellenaliase) gab, da bestimmte Spalten in mehrere Tabellen gleich hießen,

c) ... sich wunderten, warum "der Browser so lange fürs Laden braucht" - der aber gar nichts dafür konnte, weil erstmal x-Hunderttausend komplette Kundendatensätze (mit Adresse, Geburtsdatum der Oma, Schuhgröße des Nachbarn usw.) vom Datenbankserver zum Webserver geschoben wurden,

d) ...

Da nehme ich mir einfach mal heraus, wenn ich irgendwo ein "SELECT *" sehe und mir auffällt, dass es sich beim Fragenden und/oder derart Antwortenden *nicht* um einen "alten Hasen" handelt (von dem ich erwarte, dass er weiß, was er tut), darauf hinzuweisen, dass "'SELECT *' selten eine gute Idee ist".

MfG,
EKKi

[Ilja]

moin,

Richtig. Aber dieses "gleich richtig vermitteln" sollte IMHO nicht in einem Forum, sondern in einem entsprechenden Tutorial o.ä. erfolgen, in dem dann auch eingehend die Vor- und Nachteile der Verwendung von "SELECT *" behandelt werden.

sehe ich wieder anders, ein tutorial kann eher weniger leisten als ein forum, weil man dort keine rückfragen beantworten kann. hier und in anderen foren wäre schon ein sehr guter ort dafür, dinge gleich richtig zu erklären und nicht nur im bezug auf datenbanken.

In den (späteren Programm-)Code aber übernehme ich "SELECT *" aus Prinzip fast niemals - ganz einfach weil ich nicht weiß, ob sich nicht irgendwann in der Zukunft an den Datenstrukturen noch etwas ändert, ob irgendwann jemand meine Abfragen erweitert oder umbaut usw.

das ist ja weder ein argument dafür noch dagegen und deswegen ist auch das "prinzip" fehl am platze, es ist fall abhängig. SELECT * hat den vorteil oder auch nachteil, dass es sich einer veränderten datenstruktur anpasst, ohne das der code geändert werden muss. je nachdem was man eben in dem jeweiligen fall haben will, ist es ein vorteil oder eben nachteil, wenn es produktiv eingesetzt wird. wenn ich also grundsätzlich (aus prinzip) SELECT * vermeide, dann mache ich einen fehler.

In einer Schmuddelecke hat es ja auch nichts zu suchen - es ist nur ein Werkzeug, das im produktiven Einsatz mit Bedacht gewählt werden sollte.

vielleicht ist es kleinlich, aber diese aussage würde ich voll und ganz so unterschreiben, das hört sich gleich ganz anders an. es impliziert nicht gleich, das SELECT * muss hier doch falsch sein, bis hin dazu, es aus prinzip nie einszusetzen. klingt einfach professioneller diese aussage, so wie du sie gerade geschrieben hast.

Da nehme ich mir einfach mal heraus, wenn ich irgendwo ein "SELECT *" sehe und mir auffällt, dass es sich beim Fragenden und/oder derart Antwortenden *nicht* um einen "alten Hasen" handelt (von dem ich erwarte, dass er weiß, was er tut), darauf hinzuweisen, dass "'SELECT *' selten eine gute Idee ist".

wäre mir wieder zu pauschal die aussage...

Ilja

[EKKi]

Mahlzeit Ilja,

sehe ich wieder anders, ein tutorial kann eher weniger leisten als ein forum, weil man dort keine rückfragen beantworten kann.

Beim initialen "Wissen-über-Grundlagen-in-Gehirn-implantieren" sind Nachfragen kontraproduktiv (insbesondere wenn in diesen dann wieder ständig auf spezielle Einzelfälle bezug genommen wird). Ein gut strukturiertes, kurzes und prägnantes Tutorial, das zumindest die grundlegende Problematik erläutert und einige Standard-Vorgehensweisen aufzeigt, ist IMHO extrem sinnvoll, um wenigstens ansatzweise ähnliche Kenntnisstände herzustellen.

Auf dieser Basis kann man dann gerne diskutieren und philosophieren.

hier und in anderen foren wäre schon ein sehr guter ort dafür, dinge gleich richtig zu erklären und nicht nur im bezug auf datenbanken.

Nein, ein Forum ist nicht dazu da, Grundlagenwissen zu lehren (außer Du möchtest ständig ins Archiv - dessen Beiträge man eben *nicht* aktualisieren kann - verweisen oder hier auch "Sticky"-Beiträge einführen). In einem Forum diskutiert man konkrete Probleme und/oder Anwendungsfälle.

Besser geeignet wäre da IMHO entweder ein Artikel im Rahmen von "SELFHTML Aktuell" oder ein entsprechende Wiki-Artikel oder -Kurs.

das ist ja weder ein argument dafür noch dagegen und deswegen ist auch das "prinzip" fehl am platze, es ist fall abhängig.

Selten. Will ich lediglich alle Felder einer View anzeigen (z.B. im Rahmen einer tabellarischen Übersicht) und die Business-Logik zur Ermittlung dieser Werte steckt komplett in der View, dann ist natürlich ein "SELECT *" das richtige Werkzeug.

wenn ich also grundsätzlich (aus prinzip) SELECT * vermeide, dann mache ich einen fehler.

Nein. Gerade im produktiven Einsatz bei der Abfrage direkt auf Tabellen sollte ich IMHO einerseits *genau wissen*, was ich tue (und damit auch *genau wissen*, welche Spalten ich dafür brauche) und andererseits ist es in komplexen Datenbanken häufig der Fall, dass in jeder Tabelle haufenweise für die GUI bzw. den Anwender meistens unnötige (Standard-)Spalten vorhanden sind, die natürlich in jeder Tabelle genau gleich heißen und spätestens dann, wenn man mit der per "SELECT *" abgefragten Datenmenge weiterarbeiten will, zu Problemen führen *können*.

wäre mir wieder zu pauschal die aussage...

Das mag sein ... *meine* Erfahrung zeigt mir, dass das vonnöten ist. Selbst hier bei mir im Kollegenkreis sind sich einige der Probleme, die man sich mit "SELECT *" einhandeln *kann*, gar nicht bewusst - und von denen würde ich *eigentlich* entsprechende Kenntnisse erwarten.

MfG,
EKKi

[Ilja]

moin,

wenn ich also grundsätzlich (aus prinzip) SELECT * vermeide, dann mache ich einen fehler.

Nein.

das ist doch ein widerpsruch, du benutzt auf der einen seiten wörter wie "selten", "häufig", etc. und auf der andere seite pauschalisiert du. SELECT * ist nun mal fallabhängig. und da hilft auch nicht das argument gegenüber anfänger. es macht doch keinen sinn, denen erst beibringen zu wohlen, benutze SELECT * nie im produktiveinsatz und ihnen dann später zu erklären, dass dies nur für anfänger gilt und dann wenn sie mehr wissen, erzählt man ihnen die ganze wahrheit.

Selbst hier bei mir im Kollegenkreis sind sich einige der Probleme, die man sich mit "SELECT *" einhandeln *kann*, gar nicht bewusst - und von denen würde ich *eigentlich* entsprechende Kenntnisse erwarten.

das eine hat doch mit dem anderen nichts zu tun. jemanden zu sagen, setze immer SELECT * ein ist genauso falsch wie setze es nie ein. ich sage, mache lieber gleich alle wissend, sowohl deine kollegen als auch die anfänger. das tool falsch einzusetzen beruht immer auf unwissenheit und nicht am SELECT *

Ilja

[EKKi]

Mahlzeit Ilja,

das eine hat doch mit dem anderen nichts zu tun. jemanden zu sagen, setze immer SELECT * ein ist genauso falsch wie setze es nie ein.

Ich habe ja auch nicht gesagt, dass man "SELECT *" nie einsetzen soll. Ich habe lediglich gesagt, dass es selten eine gute Idee ist.

Und darüber hinaus habe ich gesagt, dass man wissen sollte, was man tut, wenn man es einsetzt - solange man das nicht weiß, ist es IMHO erst recht keine gute Idee, "SELECT *" zu verwenden ... weil es aufgrund das mangelnden Wissens relativ häufig zu Problemen kommen kann, die für einen Anfänger nicht auf den ersten Blick zu durchschauen sind.

Konsequenz für jemanden, der das liest und *nicht* um die Probleme mit "SELECT *" weiß, wäre dann doch: Wissen aneignen. Das kann man auf verschiedene Arten und Weisen tun ... die allwissende Müllhalde bedienen wäre eine, hier im Forum nachfragen wäre eine andere.

Bei Nachfragen kann man dann ja immer noch die Problematik erläutern oder auf entsprechende Quellen verweisen. Ich werde jetzt aber nicht jedesmal statt "'SELECT *' ist selten eine gute Idee" gleich ein komplettes Essay zu den Vor- und Nachteilen, zu Problemen unter Berücksichtigung von Spezifika der verschiedenen Datenbanksysteme usw. posten ...

ich sage, mache lieber gleich alle wissend, sowohl deine kollegen als auch die anfänger. das tool falsch einzusetzen beruht immer auf unwissenheit und nicht am SELECT *

Sicher. Deshalb sagte ich "SELECT * ist selten eine gute Idee" und habe das durch Beispiele ergänzt. Wenn der Fragende sich der Problematik bewusst ist, wird er sich denken "Achja, stimmt ja - da war ja was!" und das berücksichtigen. Wenn er davon zum ersten Mal hört (bzw. liest), wird er entweder nachfragen oder sich anderswo Informationen dazu verschaffen.

Tut er beides nicht, ist er hier ohnehin falsch ...

MfG,
EKKi

[Ilja]

moin,

Ich habe ja auch nicht gesagt, dass man "SELECT *" nie einsetzen soll. Ich habe lediglich gesagt, dass es selten eine gute Idee ist.

vielleicht lese ich ja deine antwort auf meine aussage falsch, aber wenn ich sage, man macht einen fehler, wenn man pauschal SELECT * ablehnt und du darauf mit einem Nein antwortest, dann weiß ich nicht, wie ich das anders deuten sollte.

wie auch immer, im grunde genommen will ich gar nicht auf deinen post im speziellen eingehen. ich sehe das wie Deldfix, SELECT * hat hier im forum immer einen negativen touch und das sollte sich ändern, das betrifft nicht nur deinen jetzigen betrag, sondern grundsätzlich hier im forum.

Und darüber hinaus habe ich gesagt, dass man wissen sollte, was man tut, wenn man es einsetzt - solange man das nicht weiß, ist es IMHO erst recht keine gute Idee, "SELECT *" zu verwenden ... weil es aufgrund das mangelnden Wissens relativ häufig zu Problemen kommen kann, die für einen Anfänger nicht auf den ersten Blick zu durchschauen sind.

das würde im umkehrschluss bedeuten, dass man SELECT spalte1, spalte2... nicht einsetzen sollte, solange man den unterschied und die genaue verwendung nicht kennt. man kann das nämlich auch falsch einsetzen, spaltennamen benutzen, obwohl ein SEELCT * an der stelle besser wäre. dann müsstest du ja auch argumentieren, es nicht einzusetzen, solange man nicht das wissen dazu hat. oder aber erst mal darauf hinzuweisen, dass SELECT * in einigen fällen besser wäre.

du kannst doch nicht jedesmal mit dem argument wissen/unwissenheit kommen und dich dann einseitig auf die verwendung von Spaltenangaben schlagen. an der richtigen stelle, richtig einsetzen. ansonsten kann man beides falsch einsetzen. aber genau so sehen die postings meistens bezüglich SEELCT * aus, es ist eine doch recht einseitige argumentation pro spaltennamen und kontra SELECT *.

das ist wie mit dem autofahren, meistens verwende ich das gas, ab und zu auch die bremse. beides ist sehr sinnvoll und beides kann ich richtig oder auch falsch einsetzen. aber nur weil jemand sagt, er geht auf die bremse, muss ich doch nicht gleich sagen, wer bremst verliert, bzw. anfängenr erst mal pauschal das gas empfehlen und nicht die bremse, nur weil man das gas öfters als die bremse benutzt. in der fahrschule wird mal mit 99,999% sicherheit den anfängern beides erklärt und auch beides richtig einzusetzen. genauso würde ich ir das mit SELECT * und SELECt spaltennamen wünschen.

Ilja

[Struppi]

das ist wie mit dem autofahren, meistens verwende ich das gas, ab und zu auch die bremse. beides ist sehr sinnvoll und beides kann ich richtig oder auch falsch einsetzen. ...

Das soll ein Vergleich sein?

Das Gas und Bremspedal sind grundsätzliche Dinge, damit das Auto überhaupt startet oder anhält. Aber damit sind die Argumente, die für oder gegen SELECT * sprechen absolut nicht vergleichbar. Kein SQL Befehl funktioniert grundsätzlich mit einer der Varianten nicht oder besser.

Wenn kann man es eher damit vergleichen ob man immer Vollgas gibt oder auch mal sparsam auf's Pedal drückt. Ich bevorzuge die zweite Variante.

Struppi.

[Ilja]

moin,

Das soll ein Vergleich sein?

jeder vergleich hinkt, aber mit guten willen zeigt er auf, worauf es ankommt, nämlich dass man beides im produktivbetrieb sinnvoll einsetzen kann. und alleine diese aussage war ja hier im forum lange zeit ein tabu.

Das Gas und Bremspedal sind grundsätzliche Dinge, damit das Auto überhaupt startet oder anhält. Aber damit sind die Argumente, die für oder gegen SELECT * sprechen absolut nicht vergleichbar. Kein SQL Befehl funktioniert grundsätzlich mit einer der Varianten nicht oder besser.

sehe ich anders, wie willst du den ohne die spalten zu kennen alle anzeigen lassen ? und umgekehrt, wie willst du dir nur ein teilbereich anzeigen lassen, mit der verwendung von SELECT * ? das was SELECT * macht, kannst du anders nicht erreichen und umgekehrt.

Wenn kann man es eher damit vergleichen ob man immer Vollgas gibt oder auch mal sparsam auf's Pedal drückt. Ich bevorzuge die zweite Variante.

du meinst sicherlich, dass man auch mal vollgas gibt und nicht immer. so wie du den vergleich geschrieben hast, fehlt ja sonst noch das entscheidene kriterium, nämlich anstelle von immer vollgas zu geben, in den relevanten situationen vollgas zu geben und dann sparsam zu fahren, wenn es sinnvoll ist.

man muss sich bewußt machen, immer SELECT * einzusetzen ist genauso falsch, wie es nie einzusetzen. es kommt eben auf den fall drauf an. und ich bin sehr wohl der meinung, dass man das auch anfängern von anfang an bewußt machen kann. ganz im gegenteil, diese sind meistens aufgeschlossener, als jemanden zu überzeugen, der verinnerlicht hat, niemals SElECT * im produktiven einsatz zu verwenden. dann nämlich gibt ees solche grundsatzdiskussionen wie hier.

Ilja

[Struppi]

jeder vergleich hinkt, aber mit guten willen zeigt er auf, worauf es ankommt, nämlich dass man beides im produktivbetrieb sinnvoll einsetzen kann. und alleine diese aussage war ja hier im forum lange zeit ein tabu.

Davon weiß ich nichts, da ich nicht alle Datenbank Threads verfolge.

Das Gas und Bremspedal sind grundsätzliche Dinge, damit das Auto überhaupt startet oder anhält. Aber damit sind die Argumente, die für oder gegen SELECT * sprechen absolut nicht vergleichbar. Kein SQL Befehl funktioniert grundsätzlich mit einer der Varianten nicht oder besser.

sehe ich anders, wie willst du den ohne die spalten zu kennen alle anzeigen lassen ? und umgekehrt, wie willst du dir nur ein teilbereich anzeigen lassen, mit der verwendung von SELECT * ? das was SELECT * macht, kannst du anders nicht erreichen und umgekehrt.

Eben, es geht darum, ob du einen Teil oder alles bekommst und bei deinem Vergleich mit Gas und Bremspedal, sind es nur zwei völlig gegensätzliche Dinge, beschleunigen oder bremsen, wir sprechen aber über alles oder nur einen Teil.

Wenn kann man es eher damit vergleichen ob man immer Vollgas gibt oder auch mal sparsam auf's Pedal drückt. Ich bevorzuge die zweite Variante.

du meinst sicherlich, dass man auch mal vollgas gibt und nicht immer. so wie du den vergleich geschrieben hast, fehlt ja sonst noch das entscheidene kriterium, nämlich anstelle von immer vollgas zu geben, in den relevanten situationen vollgas zu geben und dann sparsam zu fahren, wenn es sinnvoll ist.

Genau! Und mehr wurde hier auch nicht gesagt. EKKI hat nur keinen konkreten Vorschlag genannt, wann es sinnvoll ist Vollgas zu geben. Es ist aber auf jeden Fall seltensten sinnvoll.

man muss sich bewußt machen, immer SELECT * einzusetzen ist genauso falsch, wie es nie einzusetzen. es kommt eben auf den fall drauf an. und ich bin sehr wohl der meinung, dass man das auch anfängern von anfang an bewußt machen kann. ganz im gegenteil, diese sind meistens aufgeschlossener, als jemanden zu überzeugen, der verinnerlicht hat, niemals SElECT * im produktiven einsatz zu verwenden. dann nämlich gibt ees solche grundsatzdiskussionen wie hier.

Naja, dann verstehe ich nicht, warum ihr nicht einfach den Post von EKKI um diese Information ergänzt habt? Dann hätte man sich die "Grundsatzdiskussion" gespart, zumal keiner eine andere Meinung hat als ihr, auch EKKI hat das jetzt schon mehrfach gesagt.

Die Grundsatzdiskussion hier geht einzig um die Wertung des Begriffs "seltenst", für euch heißt er fast nie, für mich, das es manchmal sinnvoll sein kann.

Er hat ja nur auf den völlig unkommentierten Tipp reagiert, man sollte SELECT * verwenden, was ich für einseitig halte. Und gerade, wie du schon schreibst, solche unkommentierte Ratschläge die Kanone zu benutzen, verführen Anfänger dazu diese immer zu benutzen. Erst durch die Antwort von EKKI wurde der Post ausgewogen und versetzt den OP in die Lage sich Gedanken zu machen und dann aufgeschlossen zu sein. Ohne diesen Kommentar hätte er nur die Information, das alle Felder zu selektieren die Lösung ist, da sie kommentarlos im selfhtml Forum angepriesen wurde.

Struppi.

[Ilja]

moin,

Eben, es geht darum, ob du einen Teil oder alles bekommst und bei deinem Vergleich mit Gas und Bremspedal, sind es nur zwei völlig gegensätzliche Dinge, beschleunigen oder bremsen, wir sprechen aber über alles oder nur einen Teil.

nein, dann hast du nicht verstanden, worum es geht. es geht nicht um teil oder ganzes (das ist das, worauf du das beispiel reduzierst). es geht darum wie man die unterschiedlichen möglichkeiten/features (hier SELECT * oder spaltenauswahl in der projektion) richtig einsetzt, anstelle sie zu verteufeln. und darauf zielt das beispiel mit der bremse, beides sollte man im richtigen moment nutzen, wenn nicht kann es zu problemen kommen. es ist dabei aber vollkommen irrelevant, ob man es sich dabei um teile oder das ganze handelt, bzw. um zwei verschiedene pedale, zumal es auch nicht richtig ist, SELECT * als ganzes einer spaltenauswahl zu definieren. diese aussage ist nämlich falsch. ich kann sehr wohl spalten in der projektion haben, die es im SELECT * nicht gibt.

Er hat ja nur auf den völlig unkommentierten Tipp reagiert, man sollte SELECT * verwenden, was ich für einseitig halte. Und gerade, wie du schon schreibst, solche unkommentierte Ratschläge die Kanone zu benutzen, verführen Anfänger dazu diese immer zu benutzen. Erst durch die Antwort von EKKI wurde der Post ausgewogen und versetzt den OP in die Lage sich Gedanken zu machen und dann aufgeschlossen zu sein. Ohne diesen Kommentar hätte er nur die Information, das alle Felder zu selektieren die Lösung ist, da sie kommentarlos im selfhtml Forum angepriesen wurde.

sicherlich ist das pauschale verwenden von SELECT * falsch. aber ich kann mich nur wiederholen, es geht mir weniger um Ekkis beitrag, sondern um eine grundsätzliche auseinandersetzung mit dem thema SELECT * hier im forum. und das habe ich nun mehrfach gesagt.

Ilja

[Struppi]

Eben, es geht darum, ob du einen Teil oder alles bekommst und bei deinem Vergleich mit Gas und Bremspedal, sind es nur zwei völlig gegensätzliche Dinge, beschleunigen oder bremsen, wir sprechen aber über alles oder nur einen Teil.

nein, dann hast du nicht verstanden, worum es geht. es geht nicht um teil oder ganzes (das ist das, worauf du das beispiel reduzierst). es geht darum wie man die unterschiedlichen möglichkeiten/features (hier SELECT * oder spaltenauswahl in der projektion) richtig einsetzt, anstelle sie zu verteufeln. und darauf zielt das beispiel mit der bremse, beides sollte man im richtigen moment nutzen, wenn nicht kann es zu problemen kommen. es ist dabei aber vollkommen irrelevant, ob man es sich dabei um teile oder das ganze handelt, bzw. um zwei verschiedene pedale, zumal es auch nicht richtig ist, SELECT * als ganzes einer spaltenauswahl zu definieren. diese aussage ist nämlich falsch. ich kann sehr wohl spalten in der projektion haben, die es im SELECT * nicht gibt.

das ist toll, es wird also über etwas diskutiert was hier gar nicht statt gefunden hat. Dann wirfst du mir jetzt etwas hin, was ich als DB-Dau nicht nachvollziehen kann ohne zu erläutern um was es geht.

Ich muss sagen, dass ihr mich als DB Dau, mehr verwirrt habt, als das ich einen Erkenntnissgewinn aus dieser Diskussion gezogen habe.

Für mich war der Post von EKKI nachvollziehbar und verständlich. Dann höre ich von Views und von Spalten in Projektionen und dass das ein Grund ist SELECT * zu verwenden. Aber keiner geht darauf genauer ein und letztlich ist es jetzt nur ein Streit, der keine inhaltlichen Verbesserungen gebracht hat, sondern im gegenteil ich, als der öfters von euch erwähnte Anfänger, hänge jetzt in der Luft und muss damit Leben, dass ich wohl immer etwas falsch machen werde, da ich nicht weiß wie es richtig ist.

sicherlich ist das pauschale verwenden von SELECT * falsch. aber ich kann mich nur wiederholen, es geht mir weniger um Ekkis beitrag, sondern um eine grundsätzliche auseinandersetzung mit dem thema SELECT * hier im forum. und das habe ich nun mehrfach gesagt.

Die aber leider anscheinend nicht stattfindet. Für mich klingt die Reaktionen eher so: "wir kennen alle Tiefen der Datenbankprogrammierungen und werden Tipps, die Anfängern zumindest einen Weg zeigen könnten, mit unserem Detailwissen zerpflücken, da eine Pauschalisierung immer schlecht ist."

Struppi.

[Ilja]

moin,

das ist toll, es wird also über etwas diskutiert was hier gar nicht statt gefunden hat. Dann wirfst du mir jetzt etwas hin, was ich als DB-Dau nicht nachvollziehen kann ohne zu erläutern um was es geht.

ob es stattgefunden hat oder nicht, das sei mal dahingestellt. es spielt aber letzlich keine rolle. wichtig ist zu erkennen, ob man ein sinnvolles tool in der hand hält und wann/wie man es am besten einsetzt.

Für mich war der Post von EKKI nachvollziehbar und verständlich. Dann höre ich von Views und von Spalten in Projektionen und dass das ein Grund ist SELECT * zu verwenden. Aber keiner geht darauf genauer ein und letztlich ist es jetzt nur ein Streit, der keine inhaltlichen Verbesserungen gebracht hat, sondern im gegenteil ich, als der öfters von euch erwähnte Anfänger, hänge jetzt in der Luft und muss damit Leben, dass ich wohl immer etwas falsch machen werde, da ich nicht weiß wie es richtig ist.

das war auch weniger eine diksussion darum, ob SELECT * nun sinnvoll ist oder nicht. Ekki selbst hält es ja für sinnvoll, wenn ich ihn richtig verstanden habe. insofern weichen wir ja nicht von dieser meinung ab. ich sage nur, lieber gleich von anfang an richtig beibringen, auch anfänger können das verstehen.

Die aber leider anscheinend nicht stattfindet. Für mich klingt die Reaktionen eher so: "wir kennen alle Tiefen der Datenbankprogrammierungen und werden Tipps, die Anfängern zumindest einen Weg zeigen könnten, mit unserem Detailwissen zerpflücken, da eine Pauschalisierung immer schlecht ist."

erstens kennen wir nicht alle tiefen, niemand kennt alle. und es geht auch nicht darum, jemanden zu verwirren. letzlich kann jeder es so halten wie ein dachdecker. aber ich sehe ehrlich gesagt keinen sinn darin, jemanden zu sagen, benutze das und das niemals prduktiv und 6 monante später erkläre ich ihm dann, dass es doch sinn machen kann.

Ilja

[EKKi]

Mahlzeit Ilja,

das war auch weniger eine diksussion darum, ob SELECT * nun sinnvoll ist oder nicht. Ekki selbst hält es ja für sinnvoll, wenn ich ihn richtig verstanden habe.

... in den richtigen Situation und wenn es richtig und mit Bedacht eingesetzt wird.

aber ich sehe ehrlich gesagt keinen sinn darin, jemanden zu sagen, benutze das und das niemals prduktiv und 6 monante später erkläre ich ihm dann, dass es doch sinn machen kann.

Das hat doch auch nie jemand behauptet - jetzt komm doch bitte mal endlich davon runter. Ich habe lediglich gesagt, dass ich persönlich "SELECT *" seltenst für eine gute Idee halte. Nicht mehr und nicht weniger. Von "nie" war nie die Rede.

MfG,
EKKi

[Ilja]

moin,

... in den richtigen Situation und wenn es richtig und mit Bedacht eingesetzt wird.

da stimmen wir überein.

Das hat doch auch nie jemand behauptet - jetzt komm doch bitte mal endlich davon runter. Ich habe lediglich gesagt, dass ich persönlich "SELECT *" seltenst für eine gute Idee halte. Nicht mehr und nicht weniger. Von "nie" war nie die Rede.

schraube mal dein persönliches angriffsgefühl ein wenig runter, es geht hier nicht um personen. wo wir uns unterscheiden, das ist eben das vorgehen bei unerfahrenen. und ich würde sogar einen schritt weiter gehen, auch bei erfahrenen ist es immer noch ein problem, das SELECT * entweder falsch eingesetzt wird oder eben es grundsätzlich verteufelt wird. und wenn ich die aussage treffe, dass man einen fehler macht, wenn man SELECT * im produktiven einsatz grundsätzlich ablehnt und du darauf hin mit einem Nein antwortest, dann ist mir entweder nicht klar, wie das Nein gemeint ist oder aber du beziehst dich damit auf die unerfahrenen und machst einen unterschied, dass nur der erfahrene/wissende es einsetzen sollten. wobei mir nicht klar ist, warum man nicht gleich auch die anfänger zu wissenden macht.

das problem mit SELECT * ist, es wurde lange zeit verteufelt, mit sicherheit auch in vielen tutorials. hätte man gleich von anfang an eine richtige aufklärung betrieben, hätten wir heute nicht die ganze diskussion darüber, sprich keinen unterschied ob erfahren oder nicht, ob jung oder alt, ob frau oder mann, einfach mal richtig aufklären....

Ilja

[Struppi]

das problem mit SELECT * ist, es wurde lange zeit verteufelt, mit sicherheit auch in vielen tutorials. hätte man gleich von anfang an eine richtige aufklärung betrieben, hätten wir heute nicht die ganze diskussion darüber, sprich keinen unterschied ob erfahren oder nicht, ob jung oder alt, ob frau oder mann, einfach mal richtig aufklären....

Ich hab keine Ahnung welche Mission ihr verfolgt, aber ich - und ich betone noch mal, als Laie - habe diese Verteufelung nie gelesen. Es wurde immer  darauf hingewiesen  welche Probleme dabei entstehen wenn man wahllos alle Felder selektiert.

Und wenn du es schon ansprichst, von wegen Diskussion, zeig mir doch ein einzigen Thread wo jemals jemand, aufgrund der von dir angenommen falschen Beratung, ein SELECT * verwenden muss? Ich bin mir sicher es gibt keinen solchen Thread im ganzen Internet.

Worin besteht denn also Bitte diese ominöse richtige Aufklärung?
Bisher habe ich nur etwas von Views gehört, wenn ich diese jemals einsetzen sollte, werde ich mir natürlich eine entsprechende Doku durchlesen, aber ich bezweifle dass die Diskussion darüber ob SELECT * nun verteufelt werden darf oder ob es besser ist die wenigen Einzelfälle zu benutzen es nicht zu verteufeln, irgendjemanden einen Nutzen bringt.

Zumal, wie gesagt, auch diese angebliche Verteufelung oder Einseitigkeit, ich nicht wahrgenommen habe. Sondern die Argumente die dagegen sprechen waren immer verständlich und nachvollziehbar. So wie auch in diesem Thread.

Struppi.

[dedlfix]

Hi!

Ich hab keine Ahnung welche Mission ihr verfolgt, aber ich - und ich betone noch mal, als Laie - habe diese Verteufelung nie gelesen. Es wurde immer  darauf hingewiesen  welche Probleme dabei entstehen wenn man wahllos alle Felder selektiert.

Wenn du das nie so gesehen oder empfunden hast, dann fehlte dir da vermutlich die nötige Aufmerksamkeit oder das Interesse an dem Thema. Das ist aber kein Grund anzunehmen, dass es nicht existiert oder dass stets ausgewogen darüber berichtet wurde. Und das hat auch EKKi nicht gemacht. Er hat zwar Gründe geliefert, die aber nicht ausgewogen waren und sich auch nicht direkt mit der Situation des Anwenders beschäftigten, sondern nur allgemein ablehnender Art waren. Und um es nochmal zu betonen: Es geht nicht darum EKKi fertig zu machen oder ähnliches. Er war nur zufällig der Anlass und nicht die Ursache für die Notwendigkeit einer solchen Grundsatzdiskusion.

Um mal ein besondere krasses Beispiel aus der jüngsten Vergangenheit zu zeigen: </archiv/2010/6/t198620/#m1334103>. Und das ist nicht das einzige in der Art, das sich finden lässt. Auch ist Cheatah kein Einzelfall beim unbegründeten Ablehnen. Leider hatte er es nicht für nötig erachtet, seine falsche Behauptung zu verteidigen, weswegen sich an der Stelle kein Dialog entspann. Das Archiv enthält noch weitere solcher unbegründeter Behauptungen oder seltener Begründungen, die nur ablehnender Art sind, obwohl die Gründe heutzutage nicht mehr so gravierend sind, wie zur Zeit als sich diese Ablehnung zu etablieren begann (als Speicher und Rechenleistung noch ein knappes und teures Gut waren).

Worin besteht denn also Bitte diese ominöse richtige Aufklärung?

Nochmal: Es geht mir und Ilja darum ausgewogen und neutral über ein Thema zu berichten, besonders wenn man von den Umständen der konkreten Anwendung nur wenig oder keinen Einblick bekommen hat. Es gibt sicher Argumente, deren Beachtung in einer überwiegenden Mehrheit einen positiven Einfluss haben, aber auch Irrelevanz und negative Ergebnisse können sich ergeben, wenn man nicht anwendungsfallorientiert sondern nach gelernten, vereinfachten Regeln agiert.

Bisher habe ich nur etwas von Views gehört, wenn ich diese jemals einsetzen sollte, werde ich mir natürlich eine entsprechende Doku durchlesen, aber ich bezweifle dass die Diskussion darüber ob SELECT * nun verteufelt werden darf oder ob es besser ist die wenigen Einzelfälle zu benutzen es nicht zu verteufeln, irgendjemanden einen Nutzen bringt.

Ist es nicht egal, ob es wenige oder viele Fälle sind, die oftmals unbeachtet gelassen werden? Mir ist Aufklärung in allen Richtungen wichtig und dass der Anwender kompetent selbst entscheiden kann, was für seinen Anwendungsfall das Beste ist. Zugegeben, ein sehr idealistischer Wunsch.

SELECT * hat nicht nur Views als positives Anwendungsbeispiel, und schon gar nicht alle Arten von Views. SELECT * liefert alle Felder bei kürzester Syntax. Nicht mehr und nicht weniger. Wann immer man das so haben möchte oder wenn es auf die überflüssig übertragenen Daten nicht ankommt, ist SELECT * ein geeignetes Werkzeug. Und das sowohl in der produktiven Umgebung als auch beim Entwickeln und Testen von Abfragen im Labor.

Zumal, wie gesagt, auch diese angebliche Verteufelung oder Einseitigkeit, ich nicht wahrgenommen habe. Sondern die Argumente die dagegen sprechen waren immer verständlich und nachvollziehbar. So wie auch in diesem Thread.

Gut, oder auch nicht. Ich schlage vor, das Thema an der Stelle abzuschließen, da ich kein Potential sehe, dass wir und bei den verbliebenen gegensätzlichen Meinungen annähern werden. Deinen Eindruck kann ich so nicht teilen, aber ich würde mich argumentativ nur noch wiederholen.

Lo!

[Struppi]

SELECT * hat nicht nur Views als positives Anwendungsbeispiel, und schon gar nicht alle Arten von Views. SELECT * liefert alle Felder bei kürzester Syntax. Nicht mehr und nicht weniger.

Was in den seltensten Fällen wirklich nötig ist.

Das war für mich eine Erkenntnis, die mir am Anfang, als mit mySQL anfing zu arbeiten, nicht bewußt war. Deshalb war genau dieser Satz in meinen Augen der ausreichende, um mir die Problematik vor Augen zu halten.

Aus der Perspektive eines Laien, wäre jede weiterführende Erläuterung verwirrend und hätte am Ende mich vielleicht einfach trotzig weiter * verwenden lassen - es ist ja nicht so schlimm und vielleicht in manchen Fällen auch besser, egal ob die jemals eintreten.

Struppi.

[EKKi]

Mahlzeit Struppi,

SELECT * liefert alle Felder bei kürzester Syntax. Nicht mehr und nicht weniger.

Was in den seltensten Fällen wirklich nötig ist.

Mein Reden.

Nicht mehr und nicht weniger.

MfG,
EKKi

[dedlfix]

Hi!

Aus der Perspektive eines Laien, wäre jede weiterführende Erläuterung verwirrend und hätte am Ende mich vielleicht einfach trotzig weiter * verwenden lassen - es ist ja nicht so schlimm und vielleicht in manchen Fällen auch besser, egal ob die jemals eintreten.

Also bitte, das kommt ja wohl immer noch darauf an, wie man etwas formuliert und wie es der andere auffasst und nicht zuletzt auch auf den jeweiligen Willen auf beiden Seiten. Eine SELECT-*-Vermeidungsagumentation ist nicht generell ein Garant zur Trotzvermeidung. Mir geht es nicht darum Anfänger zu verwirren, aber ich will sie auch nicht mit halber Information und angeblich vereinfachenden Regeln in die Unmündigkeit führen. Der Weg ist irgendwo dazwischen und nicht an irgendeinem Rand. Jeder versucht sich einfache Lösungen für komplexe Probleme zu erstellen. Sowas gibt es aber nicht, egal wie sehr es sich ein Anfänger wünscht oder wie einfach man es einem solchen zu machen gedenkt. Wer ernsthaft optimale Lösungen sucht, kommt nicht um das Wissen über die Vielfalt der Wege und die damit verbundene Lern- und Entscheidungsbelastung herum.

Lo!

[Ilja]

moin,

Ich hab keine Ahnung welche Mission ihr verfolgt

gar keine misssion, wir geben hilfe aus unserer sichtweise, nicht mehr und nicht weniger.

Es wurde immer  darauf hingewiesen  welche Probleme dabei entstehen wenn man wahllos alle Felder selektiert.

da siehst du doch schon selbst am besten, dass es keine neutrale diskussion darüber gibt. du bist oft über die nachteile informiert worden. wie oft hat man dir die vorteile davon erklärt ?

Ilja

[Struppi]

da siehst du doch schon selbst am besten, dass es keine neutrale diskussion darüber gibt. du bist oft über die nachteile informiert worden. wie oft hat man dir die vorteile davon erklärt ?

Mir noch nie, ich hab auch nicht gefragt. Aber mir ist der "Vorteil", dass ich alle Felder auf einmal bekomme klar, ansonsten gibt es für mich keinen.

Struppi.

[Ilja]

moin,

Mir noch nie, ich hab auch nicht gefragt.

siehst du, über die risiken wirst du hinreichend informiert, egal ob du danach fragst oder nicht. über die vorteiel nicht. kannst dir doch selber damit ausmalen, dass es keine neutrale diskussion ist.

Ilja

[Struppi]

Mir noch nie, ich hab auch nicht gefragt.

siehst du, über die risiken wirst du hinreichend informiert, egal ob du danach fragst oder nicht.

Es ist aber eine ausreichende Information. Welche Risiken sollen denn dahinter stecken, dass ich nicht alle Felder selektiere?
Der einzige Risikofaktor ist doch der, das nicht alle Felder in der Abfrage vorkommen, aber das ist völlig logisch.

Ich für meinen Teil, hätte diese Information gerne viel früher gelesen, denn in meinen alten Anwendungen wimmelt es nur so von select *, ich wurde nie darauf hingewiesen. z.b. hier.

Wie gesagt, ich sehe diese Diskussion als Laie und mir bringt die Information das alle Felder zu selektieren schlecht ist wesentlich mehr, als eine Diskussion darüber, wann es nicht der Fall ist.

Struppi.

[Ilja]

Es ist aber eine ausreichende Information.

wie kann es den ausreichend sein, wenn du SELECT * an einer stelle auflöst, an der es richtig wäre ?

Ilja

[Struppi]

Es ist aber eine ausreichende Information.

wie kann es den ausreichend sein, wenn du SELECT * an einer stelle auflöst, an der es richtig wäre ?

Weil ich jetzt weiß, dass ich nur alle Felder selektieren sollte, wenn ich sie brauche.

Struppi.

[Ilja]

Weil ich jetzt weiß, dass ich nur alle Felder selektieren sollte, wenn ich sie brauche.

struppi, hand aufs herz und ich meine das jetzt nicht persönlich, aber hast du überhaupt verstanden, was ich geschrieben habe ? man soll SELECT * nicht überall auflösen, im gegenteil. eventuell sollst du dort, wo vorher spaltennamen standen es in SELECT * ändern. also noch mal, wie kann dann die information ausreichend sein ?

Ilja

[Struppi]

Weil ich jetzt weiß, dass ich nur alle Felder selektieren sollte, wenn ich sie brauche.

struppi, hand aufs herz und ich meine das jetzt nicht persönlich, aber hast du überhaupt verstanden, was ich geschrieben habe ? man soll SELECT * nicht überall auflösen, im gegenteil. eventuell sollst du dort, wo vorher spaltennamen standen es in SELECT * ändern. also noch mal, wie kann dann die information ausreichend sein ?

Ich verstehe diese Aussage nicht, was willst du mir damit sagen?

Du schreibst von irgendwelchen Risiken und von Nachteilen, wenn man den Tipp gibt, dass das selektieren von allen Feldern in den seltesten Fällen sinnvoll ist, aber nicht die Vorteile aufzählt.

Da es aber nur einen "Vorteil" gibt, nämlich der, dass man alle Felder selektiert, ist mir völlig schleierhaft worauf du hier hinaus willst.

Struppi.

[Ilja]

Da es aber nur einen "Vorteil" gibt, nämlich der, dass man alle Felder selektiert, ist mir völlig schleierhaft worauf du hier hinaus willst.

dann lass mich das mal bildlich ausdrücken, auch wenn jeder vergleich hinkt, aber probiere ihn zu verstehen, vielleicht können wir uns ohne das fachliche nähern:

paule sitzt auf einer parkbank an einer gabelung. dort gibt es zwei wege, der eine geht nach links, der andere nach rechts. links ist das krankenhaus, rechts ein gefängnis. die meisten besucher gehen nach links und machen krankenbesuche, sehr selten gibt es einen besucher, der einen kumpel aus alten tagen im gefängnis besuchen will. nun sieht paule jemand an der gabelung stehen, sieht so aus, als wüßte er nicht, wohin er gehen sollte, nach links oder rechts. offenbar ist er zum ersten mal hier in der gegend, kennt sich also noch nicht so gut aus. und da paule ein hilfsbereiter mensch ist, springt er auf und sagt ihm, er solle nach links gehen, nach rechts geht eher selten jemand. preisfrage, was hat paule trotz seiner hilfsbereitschaft falsch gemacht ?

Ilja

[Struppi]

Da es aber nur einen "Vorteil" gibt, nämlich der, dass man alle Felder selektiert, ist mir völlig schleierhaft worauf du hier hinaus willst.

dann lass mich das mal bildlich ausdrücken, auch wenn jeder vergleich hinkt, aber probiere ihn zu verstehen, vielleicht können wir uns ohne das fachliche nähern:

Also kaum mit deinen Vergleichen, du hast ein Schwarz/Weiss Problem.

Es geht ja in dem Fall nicht darum, das man etwas entweder oder macht, sondern dass das eine in den meisten Fällen die schlechter Möglichkeit ist. Und dafür ist mein Vergleich mit dem Vollgas oder sparsam fahren passender.

Die Situation worüber wir hier sprechen, trifft wohl folgende Fragestellung:

Situtaion: Auto - Vollgas - 2.Gang - Kurve
Fragestellung: Die Kurve  ist relativ steil, deshalb quietschen bei mir immer die Bremsen, was kann ich tun?

Antwort:Entweder in den 1.Gang schalten, aber Vollgas fahren ist selten eine gute Möglichkeit, verzichte lieber darauf.

Jetzt ist es so, dass der Fragende ja schon Auto fahren kann, auch wenn es offensichtlich nicht so gut ist. trotzdem hat er jetzt alle Informationen um in Zukunft besser um die Kurve zu kommen und wenn er nicht total verblödet ist, wird er auch Wissen wann er Vollgas geben sollte, da er ja durchaus weiß was dann passiert.

Jeder ist zufrieden und hat die Information, die er braucht. Nur du hälst diesen Ratschlag jetzt für Einseitig und erwartest, dass man dem Fragenden noch alle Situationen erklärt wo das Vollgas fahren einen Sinn machen kann. Und das kann ich nicht nachvollziehen, da der Fragende ja jetzt ja alle beiden Seiten kennt.

Struppi.

[Ilja]

schau, das was deldfix und ich nun inzwischen schon mehrfach ansprechen, was ich dir mit dem beispiel probiert habe klar zu machen, wo wir uns hier nur noch laufend wiederholen, ob man das eine oder das andere einsetzt, nach links oder rechts geht, das ist fallabhängig. das ist das gleiche mit daten-design, das passiert hier auch immer wieder. man sagt jemanden, dein design ist falsch und höchstwahrschenlich ist es das auch. ABER es ist kontextabhängig. insofern geht es nicht darum, ob der hilfesuchende alle informationen hat, es geht darum, dass ich als helfender erst mal alle relevanten informationen brauche, um einen geeigneten tip geben zu können. insofern kann eine antwort ohne diese informationen vorher zu erfragen nicht gut sein. klar nach dem gesetz der wahrscheinlichkeit liege ich halt öfters richtig als falsch. aber das ist keine wirklich gut hilfe in meinen augen.

und um bei deinem auto bespiel zu bleiben, wenn dir das besser gefällt, wenn du in einem rennwagen sitzt und gerade ein rennen bestreitest, dann werden wohl alle deine fans hoffen, dass du vollgas gibst.  auch hier gilt das gleiche, es ist kontext abhängig. und deldfix und ich sind es einfach leid, dass man solche pauschale aussagen trifft, egal ob nun mit dem zusatz seltenst oder nicht, OHNE vorher bei dem betreffenden rückzufragen, was er eigentlich an dieser stelle genau will. und wenn du das nicht verstehen kannst, dass man dies bezüglich immer rückfragen sollte, dann weiß ich auch nicht mehr weiter.

Ilja

[Struppi]

und um bei deinem auto bespiel zu bleiben, wenn dir das besser gefällt, wenn du in einem rennwagen sitzt und gerade ein rennen bestreitest, dann werden wohl alle deine fans hoffen, dass du vollgas gibst.

Auch hier wieder: deine Vergleiche beschreiben völlig andere Situationen. Jemand der einen Rennwagen fährt, wird wohl nie jemanden fragen müssen, ob er Vollgas fahren soll.

Du scheinst davon auszugehen, dass in dem Moment, wo man etwas fragt, ist man automatisch blöd und hat von der Materie keinerlei Ahnung. Ich trau den Fragenden da wesentlich mehr zu (auch wenn sich das nicht immer bestätigt)

auch hier gilt das gleiche, es ist kontext abhängig. und deldfix und ich sind es einfach leid, dass man solche pauschale aussagen trifft, egal ob nun mit dem zusatz seltenst oder nicht, OHNE vorher bei dem betreffenden rückzufragen, was er eigentlich an dieser stelle genau will. und wenn du das nicht verstehen kannst, dass man dies bezüglich immer rückfragen sollte, dann weiß ich auch nicht mehr weiter.

Ich verstehe das, aber offensichtlich versteht ihr mich nicht, dass es für mich als Laien mehr bringt, wenn ich eine pauschale Aussage bekomme. Da sie mich eher in die Lage versetzt, mich damit auseinanderzusetzen, als wenn ich davon nie etwas höre oder mir Sachen um die Ohren geworfen werden, die ich nicht verstehe, da ich sie zum aktuellen Zeitpunkt nicht brauche.

Und ich glaube, ich habe das mit meinem Beispiel sehr treffend erklärt, dass selbst eine Aussage wie "vollgasfahren ist Scheiße", für denjenigen der fragt durchaus hilfreich und nützlich ist. Auch wenn sie nicht alle Aspekte des Gasgebens berücksichtigt, aber der Fragende hat den Führerschein (resp. mysql Kenntnisse) und sollte also durchaus in der Lage sein, diese Aussage in den passenden Kontext zu bringen.

Struppi.

[dedlfix]

Hi!

Ich verstehe das, aber offensichtlich versteht ihr mich nicht, dass es für mich als Laien mehr bringt, wenn ich eine pauschale Aussage bekomme. Da sie mich eher in die Lage versetzt, mich damit auseinanderzusetzen, als wenn ich davon nie etwas höre oder mir Sachen um die Ohren geworfen werden, die ich nicht verstehe, da ich sie zum aktuellen Zeitpunkt nicht brauche.

Doch, ich verstehe dich. Du willst es einfach haben. Aber ich kann und will nicht ständig hinter dir stehen und überprüfen, wann deine einfache Regel richtig angewendet ist und wann nicht. Und du wirst ganz sicher auch nicht in jedem Fall nachfragen wollen, ob die Regel passt. Deswegen bleibt dir nichts anderes übrig, als das komplexe Wissen der Wirkungsweise statt der einen Regel zu erlernen, wenn du es richtig machen willst.

Lo!

[Struppi]

Ich verstehe das, aber offensichtlich versteht ihr mich nicht, dass es für mich als Laien mehr bringt, wenn ich eine pauschale Aussage bekomme. Da sie mich eher in die Lage versetzt, mich damit auseinanderzusetzen, als wenn ich davon nie etwas höre oder mir Sachen um die Ohren geworfen werden, die ich nicht verstehe, da ich sie zum aktuellen Zeitpunkt nicht brauche.

Doch, ich verstehe dich. Du willst es einfach haben.

Nein, ich will nicht einfach haben, das ist nur ein Nebeneffekt. Ich halte nur die Vereinfachung für einen legitimen Weg, um auf Dinge aufmerksam zu machen oder gemacht zu werden, die eigentlich innerhalb des Wissenhorizints sein müßten.

Aber ich kann und will nicht ständig hinter dir stehen und überprüfen, wann deine einfache Regel richtig angewendet ist und wann nicht. Und du wirst ganz sicher auch nicht in jedem Fall nachfragen wollen, ob die Regel passt.

Muss ja auch keiner. Das ist die Hypothese von euch. Jemand der fragt weiß automatisch so wenig, dass er mit einer einfach Regel nichts anfangen kann. Ich behaupte das gegenteil, jemand der fragt muss schon etwas Wissen, sonst würde er sich nicht mit dem Thema beschäftigen.

Deswegen bleibt dir nichts anderes übrig, als das komplexe Wissen der Wirkungsweise statt der einen Regel zu erlernen, wenn du es richtig machen willst.

So ist es aber nicht, er kennt ja schon zwei Regel, seine bisherige und die Neue. Und ob das wirklich um komplexes Wissen geht, mag ich bezweifeln und kam bisher hier auch nicht rüber. Es geht darum ob man immer alle Felder selektiert oder nur die man benötigt. Das dürfte für jemanden der Programmieren kann und mysql benutzt, durchaus innerhalb eines einfach Horizonts sein.

Struppi.

[dedlfix]

Hi!

Das ist die Hypothese von euch. Jemand der fragt weiß automatisch so wenig, dass er mit einer einfach Regel nichts anfangen kann. Ich behaupte das gegenteil, jemand der fragt muss schon etwas Wissen, sonst würde er sich nicht mit dem Thema beschäftigen.

Ich versuche meine Vorurteile schon noch sehr gezielt auf das abzustimmen, was ich sehe. Ob jemand Wissen hat, urteile ich nicht pauschal daraus dass er fragt, sondern wie er das macht. Das Ergebnis hängt von meiner Tagesform ab und ob ich der Anfrage genügend Information entnehmen kann. Ich kann jedenfalls nicht pauschal sagen, dass Frager unwissend sind, sondern schätze das fehlende Wissen fallabhängig ein. Und genauso wie ich in meinen Anwendungsfällen nicht das meistens Beste sondern das fallspezifisch Beste suche, so versuche ich das bei Problemen anderer. Die Erfahrung lehrt, dass bestimmte Dinge gern falsch gemacht oder nicht berücksichtigt werden. Wenn ich so einen Fall vermute, dann äußere ich diese Vermutung, aber möglichst als solche und nicht als Fakt.

Deswegen bleibt dir nichts anderes übrig, als das komplexe Wissen der Wirkungsweise statt der einen Regel zu erlernen, wenn du es richtig machen willst.
So ist es aber nicht, er kennt ja schon zwei Regel, seine bisherige und die Neue. Und ob das wirklich um komplexes Wissen geht, mag ich bezweifeln und kam bisher hier auch nicht rüber. Es geht darum ob man immer alle Felder selektiert oder nur die man benötigt. Das dürfte für jemanden der Programmieren kann und mysql benutzt, durchaus innerhalb eines einfach Horizonts sein.

Ich bin in meiner Argumentation schon eine Weile beim Generellen gelandet, so dass sich mein voriges Posting nicht direkt auf den nicht sehr komplexen SELECT-*-Fall bezog.

Lo!

[Ilja]

Das ist die Hypothese von euch. Jemand der fragt weiß automatisch so wenig, dass er mit einer einfach Regel nichts anfangen kann. Ich behaupte das gegenteil, jemand der fragt muss schon etwas Wissen, sonst würde er sich nicht mit dem Thema beschäftigen.

nun redest du aber wirklch unsinn. du argumentierst doch die ganze zeit, dass die volle wahrheit zu komplex für einen anfänger ist und wir dich damit nur verwirren. ich sage, auch ein anfänger ist nicht dumm und er wird es verstehen, wenn er den will.

Ilja

[Ilja]

Ich verstehe das, aber offensichtlich versteht ihr mich nicht, dass es für mich als Laien mehr bringt, wenn ich eine pauschale Aussage bekomme. Da sie mich eher in die Lage versetzt, mich damit auseinanderzusetzen, als wenn ich davon nie etwas höre oder mir Sachen um die Ohren geworfen werden, die ich nicht verstehe, da ich sie zum aktuellen Zeitpunkt nicht brauche.

struppi, nur weil du anfänger bist, dist du doch nicht dumm. es macht keinen sinn, anfänger nur einen INNER JOIN beizubringen und keine OUTER JOINS zu verwenden, weil sie ein wenig schwieriger zu verstehen sind. verstecke dich doch nicht hinter solch einer pauschalen aussage, die einfach mal falsch ist, nur weil es in den meisten fällen aufgrund der wahrscheinlichkeit passt. ich traue dir da mehr zu als du selbst. und nicht zu vergessen, hinterher ist es viel schwieriger, solches vorgehen wieder raus zu bekommen. man kann pauschlaisieren, aber bitte dort, wo die regel auch immer gilt. wenn entscheidungen kontext abhängig sind, das ist nun auch wieder nicht so schweirig zu vestehen. wir glauben an dich struppi, gib nicht auf.....

Ilja

[Struppi]

Ich verstehe das, aber offensichtlich versteht ihr mich nicht, dass es für mich als Laien mehr bringt, wenn ich eine pauschale Aussage bekomme. Da sie mich eher in die Lage versetzt, mich damit auseinanderzusetzen, als wenn ich davon nie etwas höre oder mir Sachen um die Ohren geworfen werden, die ich nicht verstehe, da ich sie zum aktuellen Zeitpunkt nicht brauche.

struppi, nur weil du anfänger bist, dist du doch nicht dumm. es macht keinen sinn, anfänger nur einen INNER JOIN beizubringen und keine OUTER JOINS zu verwenden, weil sie ein wenig schwieriger zu verstehen sind.

Ich kann mal wieder deinen Ausführungen nicht folgen. Du vergleichst Dinge, die mit der Thematik hier nicht viel zu tun haben. Es geht weder um Beibringen, noch um die eine Technik oder die andere. Es geht um diese pauschalen Ausagen, dass ein kurzer Tipp, der nicht unbedingt jeden Aspekt berücksichtigt, nicht sinnvoll wäre und dem möchte ich aus eigener Erfahrung vehement widersprechen.

Wenn es darum geht jemanden etwas zu lehren oder in die Tiefen einzutauchen, dann habt ihr Recht. Aber ich sehe mich hier nicht als Lehrer und ich glaube auch nicht, dass das viele hier erwarten.

.. und nicht zu vergessen, hinterher ist es viel schwieriger, solches vorgehen wieder raus zu bekommen.

Das ist das Problem, für dich und dedlfix bedeutet eine solche Regel, das derjenige der fragt sie nicht im Kontext sehen kann und das halte ich für falsch. Eine pauschale Regel ist hilfreich und kann gerade dann wenn sie übertrieben formuliert wird einen Anfänger, der u.U. ja bereits eingefahren ist und immer das eine verwendet, weil er es so gelernt hat, zum Nachdenken anregen.

wenn entscheidungen kontext abhängig sind, ...

genau das ist das was ich hier die ganze Zeit propagiere, der Kontext, dass wir es hier nicht mit Dummköpfen zu tun haben, denen du etwas hinwirfst und danach sind sie "verzogen", sondern die meisten sind durchaus in der Lage ihren Kontext zu begreifen, aber manchmal benötigen sie eine drastische, vielleicht in dem Einzelfall übertrieben einseitige Formulierung, um ihre Möglichkeiten Entscheidungen zu treffen, zu erweitern.

Struppi.

[dedlfix]

Hi!

Das ist das Problem, für dich und dedlfix bedeutet eine solche Regel, das derjenige der fragt sie nicht im Kontext sehen kann und das halte ich für falsch. Eine pauschale Regel ist hilfreich und kann gerade dann wenn sie übertrieben formuliert wird einen Anfänger, der u.U. ja bereits eingefahren ist und immer das eine verwendet, weil er es so gelernt hat, zum Nachdenken anregen.

Wir versuchen dir die ganze Zeit zu erklären, dass Pauschalisierungen nicht immer hilfreich sind und es stattdessen besser wäre, anwendungsfallspezifisch zu entscheiden. Das gelingt uns anscheinend nicht, denn du unterstellst uns immer wieder Pauschalisierungen unter anderem beim Behandeln der hier vorgetragenen Probleme und Probleminhaber. Ich gebe auf.

Lo!

[Struppi]

Ich gebe auf.

Das könnte eigentlich nur ich, da ich die ganze Zeit versuche, euch zu erklären, dass es aus der Perspektive eines Laien so ist, dass solche Aussagen durchaus hilfreich sind und eben nicht dazu führen, dass man sich nicht mehr mit dem Problem auseinandersetzt, sondern eher dazu führen dass man sich mehr Gedanken macht. Eher als langatmige Erklärungen über Sonderfälle.

Zumindest bei mir ist das so und daher habe ich auf die, in meinen Augen übertriebene Reaktion deinerseits, auf EKKIs Beitrag geantwortet. Aber ihr scheint das nicht zu glauben, ich hoffe halt, dass es niemanden davon abhält weiterhin Tipps zu geben, die aus dem Auge eines Fachmanns unter umständen einseitig erschienen.

Struppi.

[dedlfix]

Hi!

Ich gebe auf.
Das könnte eigentlich nur ich, da ich die ganze Zeit versuche, euch zu erklären, dass es aus der Perspektive eines Laien so ist, dass solche Aussagen durchaus hilfreich sind und eben nicht dazu führen, dass man sich nicht mehr mit dem Problem auseinandersetzt, sondern eher dazu führen dass man sich mehr Gedanken macht. Eher als langatmige Erklärungen über Sonderfälle.

Pauschalisierung. Immer wieder. Für den einen mag das so sein, aber wieso sollte das für alle gleich sein? Warum darf ich nicht individuell anhand der mir bekannten Informationen entscheiden, ob ich was Allgemeines erzähle oder was konkret auf seinen Fall bezogen?

Zumindest bei mir ist das so und daher habe ich auf die, in meinen Augen übertriebene Reaktion deinerseits, auf EKKIs Beitrag geantwortet. Aber ihr scheint das nicht zu glauben, ich hoffe halt, dass es niemanden davon abhält weiterhin Tipps zu geben, die aus dem Auge eines Fachmanns unter umständen einseitig erschienen.

Du bist aber nicht das Maß aller Dinge. Und ich maße mir auch nicht an, pauschal zu wissen, was für den Einzelnen gut ist, sondern versuche neutral zu bleiben, auch wenn ich aufgrund noch fehlender Information eine spezielle Lösung oder ein Vorgehen propagiere, das in den überwiegend zum Ziel führt oder besser ist. Dass EKKi nun der Blitzableiter war, war auch zum gewissen Teil Zufall. Irgendwann entlädt sich auch mal das was sich über einen Zeitraum lang aufstaut. Meine Erfahrungen sind eben andere als du sie gemacht hast. Gib meinetwegen pauschale Hinweise, aber gestatte mir, dass ich darauf reagiere, sie relativiere oder gegensätzliche Eigenschaften erwähne.

Lo!

[Ilja]

moin,

Das könnte eigentlich nur ich, da ich die ganze Zeit versuche, euch zu erklären, dass es aus der Perspektive eines Laien so ist, dass solche Aussagen durchaus hilfreich sind und eben nicht dazu führen, dass man sich nicht mehr mit dem Problem auseinandersetzt, sondern eher dazu führen dass man sich mehr Gedanken macht.

dass pauschalisierung und einseitigen erklärungen dem ganzen thema schaden, kann man aus zahlreichen diskussionen erkennen, wo selbst von fortgeschrittenen SQlern von dem benutzen von SELECT * abgeraten wird. es tritt also eher der gegenteilige effekt ein, dass man sich später nicht noch mal  mit dem thema neutral auseinander setzt, sondern das einmal gelernte setzt sich meistens fest.

und was die laien betrifft, ich halte sie für nicht überfordert, wenn man genauer differenziert. und wir reden hier nicht von hoch komplizierten themen, sondern von zwei verschiedenen fällen, von genau zwei ! was anfänger brauchen sind klare und vor allem richtige aussagen. ich behaupte einfach mal, dass man auch dir das thema ohne abschreckende wirkung nahe bringen kann, wann man was einsetzt. und du wirst dich wundern, wie trivial es letzlich ist.

Ilja

[Struppi]

dass pauschalisierung und einseitigen erklärungen dem ganzen thema schaden, kann man aus zahlreichen diskussionen erkennen, wo selbst von fortgeschrittenen SQlern von dem benutzen von SELECT * abgeraten wird.

Weil es meistens richtig ist. Ich finde Pauschalisierungen gut und mir haben sie immer weiter geholfen, um mich mit einem komplexen Thema auseinaderzusetzen.

Wenn das bei euch nicht so war, dann bringt natürlich die ganze Diskussion nichts, ich wollte es einfach nur mal erwähnt haben, dass es bei mir so ist und mich daher auch viele Debatten nur verwirrt haben, da sie einen einfachen Sachverhalt unnötig verkomplizeren.

und was die laien betrifft, ich halte sie für nicht überfordert, wenn man genauer differenziert. und wir reden hier nicht von hoch komplizierten themen, sondern von zwei verschiedenen fällen, von genau zwei ! was anfänger brauchen sind klare und vor allem richtige aussagen.

Genau!
Das dauernde Selektieren von allen Feldern ist selten eine gute Idee, das ist eine solche klare und richtige Aussage.

Struppi.

[Ilja]

Weil es meistens richtig ist. Ich finde Pauschalisierungen gut und mir haben sie immer weiter geholfen, um mich mit einem komplexen Thema auseinaderzusetzen.

nochmal, ich bezweifel, dass wenn es konkret darum gehen würde, wann man was benutzt, würdest du es verstehen und nicht kompliziert finden. du hättest anstelle einer pauschalisierung mehr wissen.

Wenn das bei euch nicht so war, dann bringt natürlich die ganze Diskussion nichts, ich wollte es einfach nur mal erwähnt haben, dass es bei mir so ist und mich daher auch viele Debatten nur verwirrt haben, da sie einen einfachen Sachverhalt unnötig verkomplizeren.

nicht jede debatte muss so geführt werden, dass alle sie verstehen. ich denke mal, diesen ansatz kann man getrost vergessen. hier im forum gibt es viele themen, die ich nicht nachvollziehen kann. dewwegen machen sie trotzdem sinn.

Das dauernde Selektieren von allen Feldern ist selten eine gute Idee, das ist eine solche klare und richtige Aussage.

ist sie nicht, ganz definitiv nicht. was ist den daran klar, der anwender weiß damit immer noch nicht, was er nun tun muss. die aussage ist vollkommen unklar. das sollte doch klar sein oder ? ;-)

Ilja

[EKKi]

Mahlzeit Ilja,

Das dauernde Selektieren von allen Feldern ist selten eine gute Idee, das ist eine solche klare und richtige Aussage.

ist sie nicht, ganz definitiv nicht. was ist den daran klar, der anwender weiß damit immer noch nicht, was er nun tun muss.

Doch: er könnte beispielsweise anfangen, sich zu informieren - er könnte nachfragen.

die aussage ist vollkommen unklar. das sollte doch klar sein oder ? ;-)

Die Aussage an sich ist völlig klar. Richtig ist sie außerdem. Und im *SELF*HTML-Forum (in dem Hilfe zur Selbsthilfe das Ziel ist, nicht das mundgerechte Vorkauen) auch vollkommen angebracht.

Ich weiß immer noch nicht, was Euer beider Problem ist.

MfG,
EKKi

[Ilja]

moin,

Doch: er könnte beispielsweise anfangen, sich zu informieren - er könnte nachfragen.

du meinst erst im forum hier fragen und nach den antworten muss man sich danach erst noch mal woanders informieren, was man nun eigentlich konkret tun sollte ?

Die Aussage an sich ist völlig klar. Richtig ist sie außerdem. Und im *SELF*HTML-Forum (in dem Hilfe zur Selbsthilfe das Ziel ist, nicht das mundgerechte Vorkauen) auch vollkommen angebracht.

ob sie richtig ist, sei mal dahin gestellt, ich benutze SELECT * mehr als die explizite spaltenangabe, sicherlich meistens für adhoc abfragen, aber das zählt ja mal zum produktiven einsatz dazu und ist ein vorteil von rdbms. und die aussage stellt mal in bezug auf eine konkrete anwendung gar nichts klar. wenn du dich morgens entscheiden musst, ob du einen regenschirm zur arbeit mitnimmst, was macht dann die aussage klar: meistens scheint die sonne. dann gehst du raus und stehst ohne regenschirm im regen., weil es gerade an diesem tag wie aus allen kübeln runter kommt. kann es vielleicht sein, dass du es von fall zu fall diferenzierst siehst, ob du den regenschirm einpackst oder nicht ?

und das thema mit dem SELF HTML bezieht auf HTML und nicht datenbanken, lach.

Ilja

[EKKi]

Mahlzeit Ilja,

und das thema mit dem SELF HTML bezieht auf HTML und nicht datenbanken, lach.

Ach sooooo ... man muss hier nur *HTML*-Grundkenntnisse haben und darf ansonsten in den einzelnen Themenbereichen wild und planlos absolute Grundlagenfragen stellen ohne sich vorher informiert zu haben und vor allem ohne mitdenken zu müssen? Interessant - wusste ich noch nicht. Da habe ich das Forum bisher ja offenbar ganz falsch verstanden ...

MfG,
EKKi

[Ilja]

Da habe ich das Forum bisher ja offenbar ganz falsch verstanden ...

kannste mal sehen, man lernt nie aus. aber spass beseite, das argument mit webseiten namen "SELFhtml" wird hier ja öfters gebracht, wie groß muss der eigenanteil sein, bevor man konkrete fragen stellen darf, etc. und die diskussion darüber würde ich mir gerne ersparen, die ist noch länger als diese hier. und ganz ehrlich, ich halte diesen ansatz für schwachsinn. aber das ist wie gesagt ein anderes thema. hauptsache dir ist klar geworden, dass man mit solchen aussagen wie häufig, selten, manchmal, ab und zu... im konkreten fall nichts anfangen kann.

Ilja

[Struppi]

Doch: er könnte beispielsweise anfangen, sich zu informieren - er könnte nachfragen.

du meinst erst im forum hier fragen und nach den antworten muss man sich danach erst noch mal woanders informieren, was man nun eigentlich konkret tun sollte ?

Das ist der Fall, wenn die Antwort ausgiebig ist und die vielen Möglichkeiten die es u.U. gibt erwähnt.

Aber es geht ja auch nicht unbedingt um konkrete Fragestellung, sondern vor allem um Seiteneffekte, die nicht unbedingt zum eigentlichen Thema gehören. Bei denen man nicht weiß, ob der Fragsteller sich damit auseinandergesetzt hat oder nicht. Da ist ein kurzer pauschaler Tipp goldrichtig.

wenn du dich morgens entscheiden musst, ob du einen regenschirm zur arbeit mitnimmst, was macht dann die aussage klar: meistens scheint die sonne. dann gehst du raus und stehst ohne regenschirm im regen., weil es gerade an diesem tag wie aus allen kübeln runter kommt. kann es vielleicht sein, dass du es von fall zu fall diferenzierst siehst, ob du den regenschirm einpackst oder nicht ?

Genau, diesmal ist dein Beispiel treffend.

Es gibt so Wörter wie meist, selten, fast immer, häufig, manchmal usw. Sie drücken aus, dass etwas nicht immer gut/richtig/optimal sein muss, aber in der Regel schon. Und es ist ja wohl eher so, dass du den Regenschirm nicht immer dabei hast. Aber wenn du glaubst, dass du den Leuten erklären musst warum sie den Regenschirm mitnehmen sollten, sei es dir ungenommen. Mich verwirrt sowas, weil es mir klar ist und ich denke auch den meisten anderen.

Struppi.

[Ilja]

du meinst erst im forum hier fragen und nach den antworten muss man sich danach erst noch mal woanders informieren, was man nun eigentlich konkret tun sollte ?

Das ist der Fall, wenn die Antwort ausgiebig ist und die vielen Möglichkeiten die es u.U. gibt erwähnt.

dann macht ihr das mal so, ich bin da lieber konkreter und fallspezifisch. die wischi-waschi aussagen überlasse ich gerne anderen. und mir macht es auch nichts aus, wenn jemand ohne viel vorwissen auf ein problem eine ganz konkrete lösung sucht. dann bekommt er sie auch von mir. ich musss ja nicht gleich immer weltverbesserer und hobby pädagoge spielen.

aber wenn du glaubst, dass du den Leuten erklären musst warum sie den Regenschirm mitnehmen sollten, sei es dir ungenommen. Mich verwirrt sowas, weil es mir klar ist und ich denke auch den meisten anderen.

klar, für dich würde die antwort reichen, meistens scheint die sonne und als schlußfolgerung nimmst du dann auch nie einen regenschirm mit, egal wie das wetter wirklich ist. und wenn du dann im regen stehst undd damit happy bist, weil dich die fallunterscheidung überfordert und verwirrt hätte, dann ist ja alles gesagt. ich für meinen teil erkläre den leuten weiter, dass unabhängig wie oft die sonne scheint, dass es sinn macht sich das konkrete wetter anzuschauen und daran seine entscheidung fest macht. da bin ich halt altmodisch....

Ilja

[Struppi]

aber wenn du glaubst, dass du den Leuten erklären musst warum sie den Regenschirm mitnehmen sollten, sei es dir ungenommen. Mich verwirrt sowas, weil es mir klar ist und ich denke auch den meisten anderen.

klar, für dich würde die antwort reichen, meistens scheint die sonne und als schlußfolgerung nimmst du dann auch nie einen regenschirm mit, egal wie das wetter wirklich ist.

Du hast das Wort meistens immer noch nicht verstanden.

und wenn du dann im regen stehst undd damit happy bist, weil dich die fallunterscheidung überfordert und verwirrt hätte, dann ist ja alles gesagt. ich für meinen teil erkläre den leuten weiter, dass unabhängig wie oft die sonne scheint, dass es sinn macht sich das konkrete wetter anzuschauen ..

Was ich für eine Selbverständlichkeit halte.

Wenn für dich das Wort meistens nicht ausreicht, um dir genau diese Gedanken über einen Einzelfall zu machen, dann ist das natürlich problematisch.

Wie gesagt, ich halte die meisten die hier Fragen für klug genug, dass sie ihren konkreten Einzelfall auf pauschale Aussagen anwenden können.

Aber es spricht auch nichts dagegen, wenn man den Eindruck hat, das der Fragenden diese Transferfähigkeit nicht hat, auch einmal etwas auschweifender zu werden, wobei man dann aber aufpassen muss dass derjenige nicht überfordert wird.

Struppi.

[Ilja]

Wenn für dich das Wort meistens nicht ausreicht, um dir genau diese Gedanken über einen Einzelfall zu machen, dann ist das natürlich problematisch.

ich stelle mir das gerade bildlich in einem gespräch zwischen einem paar vor.

Frau: soll ich einen regeschirm mitnehmen
Mann: Meistens scheint die sonne....
Frau: (holt das nudelholz)

Ilja

[Struppi]

Wenn für dich das Wort meistens nicht ausreicht, um dir genau diese Gedanken über einen Einzelfall zu machen, dann ist das natürlich problematisch.

ich stelle mir das gerade bildlich in einem gespräch zwischen einem paar vor.

... bei dem die Frau so dumm ist, nicht zu merken wenn es regnet?

Struppi.

[Struppi]

Wenn für dich das Wort meistens nicht ausreicht, um dir genau diese Gedanken über einen Einzelfall zu machen, dann ist das natürlich problematisch.

ich stelle mir das gerade bildlich in einem gespräch zwischen einem paar vor.

... bei dem die Frau so dumm ist, nicht zu merken wenn es regnet?

Ich finde übrigens nach wie vor, mein Beispiel mit dem Gasgeben wesentlich besser. Da es Nachteile hat immer Vollgas zu geben, der Fahrer Kenntnis haben sollte, was gasgeben bedeutet und jeder da seinen persönlichen Stil hat.

Struppi.

[Ilja]

Ich finde übrigens nach wie vor, mein Beispiel mit dem Gasgeben wesentlich besser. Da es Nachteile hat immer Vollgas zu geben

zum 100 mal, es hat auch nachteile, die spaltennamen explizit anzuführen und nicht SELECT * zu benutzen, glaube es oder glaube es nicht.

Ilja

[Struppi]

Ich finde übrigens nach wie vor, mein Beispiel mit dem Gasgeben wesentlich besser. Da es Nachteile hat immer Vollgas zu geben

zum 100 mal, es hat auch nachteile, die spaltennamen explizit anzuführen und nicht SELECT * zu benutzen, glaube es oder glaube es nicht.

Ja? Exakt das habe ich geschrieben.

Struppi.

[Struppi]

Ich finde übrigens nach wie vor, mein Beispiel mit dem Gasgeben wesentlich besser. Da es Nachteile hat immer Vollgas zu geben

zum 100 mal, es hat auch nachteile, die spaltennamen explizit anzuführen und nicht SELECT * zu benutzen, glaube es oder glaube es nicht.

Ja? Exakt das habe ich geschrieben.

.. als ich dir Beispiel erläutert habe.

Struppi.

[Ilja]

zum 100 mal, es hat auch nachteile, die spaltennamen explizit anzuführen und nicht SELECT * zu benutzen, glaube es oder glaube es nicht.

Ja? Exakt das habe ich geschrieben.

und wo bitte steht bei diesem text...

"Ich finde übrigens nach wie vor, mein Beispiel mit dem Gasgeben wesentlich besser. Da es Nachteile hat immer Vollgas zu geben"

...das es auch nachteile haben kann, nicht immer vollgas zu geben ? das ist und bleibt kontext abhängig, genauso mit der verwendung von SELECT *. die annahme, man muss ab und zu vom gas gehen ist einfach nur dumm, ohne dass man das umfeld dazu kennt. sorry, dass ich jetzt einfach mal zu harten worte greife, aber ich bin ein wenig ratlos. aussage wie oft, selten, meistens, vielleicht sind keine hilfreiche info. ich werde doch wohl einem rennfahrer was ganz anderes sagen als einen sonntagsfahrer.

was ich und deldfix hören wollen, kein selten, kein oft, kein nie, kein immer, sondern in abhängigkeit davon, was du machen willst und zwar von anfang an so zu vermitteln. ist das echt so schwierig zu verstehen ?

Ilja

[Struppi]

zum 100 mal, es hat auch nachteile, die spaltennamen explizit anzuführen und nicht SELECT * zu benutzen, glaube es oder glaube es nicht.

Ja? Exakt das habe ich geschrieben.

und wo bitte steht bei diesem text...

Ich hatte dieses Beispiel bereits ausführlicher beschrieben.

...das es auch nachteile haben kann, nicht immer vollgas zu geben ? das ist und bleibt kontext abhängig, genauso mit der verwendung von SELECT *. die annahme, man muss ab und zu vom gas gehen ist einfach nur dumm, ohne dass man das umfeld dazu kennt.

was ist daran dumm? Es ist eher dumm immer Vollgas zu geben und es ist Vernüftig meistens kein Vollgas zu geben.

sorry, dass ich jetzt einfach mal zu harten worte greife, aber ich bin ein wenig ratlos. aussage wie oft, selten, meistens, vielleicht sind keine hilfreiche info. ich werde doch wohl einem rennfahrer was ganz anderes sagen als einen sonntagsfahrer.

Genau das ist wohl das Problem, du unterscheidest die Leute hier danach. Für mich sind es alles Verkehrsteilnehmer.

was ich und deldfix hören wollen, kein selten, kein oft, kein nie, kein immer, sondern in abhängigkeit davon, was du machen willst und zwar von anfang an so zu vermitteln. ist das echt so schwierig zu verstehen ?

Das klingt für mich - um beim dem Beispiel zu bleiben - das ihr von der Annahme ausgeht in der Fahrschule sitzen angehende Rennfahrer und Sonntagsfahrer. Ich gehe erst mal davon aus die Leute wollen einfach nur Auto fahren und die meisten werden sich nie in ein Rennauto setzen, aber dem potentiellen Sonntagsfahrer kann man helfen seinen Stil zu verbessern.

Da ihr aber Rennfahrer seit, steht ihr auf dem Standpunkt, die Leute  müssen auf jeden Fall auch Wissen, dass wenn man in einem Rennauto  fast immer Vollgas geben muss. Folglich sind für euch alle dumm, die sagen, das man nur selten Vollgas geben sollte, weil eure Erfahrungen andere sind.

Struppi.

[Ilja]

was ist daran dumm? Es ist eher dumm immer Vollgas zu geben und es ist Vernüftig meistens kein Vollgas zu geben.

und da ist dein denkfehler, es kann auch sinn machen, immer vollgas zu geben, so wie es sinn machen kann, immer SELECT * zu verwenden. es ist wie nun schon gefühlt 1 million mal erwähnt kontext abhängig. wie ich bereits sagte, glaube es oder glaube es nicht.

Ilja

[Struppi]

was ist daran dumm? Es ist eher dumm immer Vollgas zu geben und es ist Vernüftig meistens kein Vollgas zu geben.

und da ist dein denkfehler, es kann auch sinn machen, immer vollgas zu geben, so wie es sinn machen kann, immer SELECT * zu verwenden. es ist wie nun schon gefühlt 1 million mal erwähnt kontext abhängig. wie ich bereits sagte, glaube es oder glaube es nicht.

Wieso sollte ich es nicht glauben, es ist ja genau das was ich sage, wenn ich das Wort meistens verwende.

Ich verfolge grad einen ähnlichen Fall:
https://forum.selfhtml.org/?t=199139&m=1339026
Hier würde ich mir eine Aussage wünschen wie, "subselects sind meistens joins vorzuziehen" oder umgekehrt. Aus deinen Ausführungen dort ist mir aber nicht klar was jetzt wirklich Vorteile hat. Sondern du betrachtest nur diesen einen Einzelfall.

Nach deiner Logik, müßte ich - wenn ich alle meine Abfragen in den Anwendungen darauf überprüfen wollte - dir alle hunderte Joins zeigen, damit du mir sagen kannst, in welchem Kontext ich mich bewege und ob im Einzelfall ein join oder ein subselect besser ist.

Struppi.

[Ilja]

Nach deiner Logik, müßte ich - wenn ich alle meine Abfragen in den Anwendungen darauf überprüfen wollte - dir alle hunderte Joins zeigen, damit du mir sagen kannst, in welchem Kontext ich mich bewege und ob im Einzelfall ein join oder ein subselect besser ist.

das mag dir nicht gefallen, aber ganz genauso so ist es.

Ilja

[Struppi]

Nach deiner Logik, müßte ich - wenn ich alle meine Abfragen in den Anwendungen darauf überprüfen wollte - dir alle hunderte Joins zeigen, damit du mir sagen kannst, in welchem Kontext ich mich bewege und ob im Einzelfall ein join oder ein subselect besser ist.

das mag dir nicht gefallen, aber ganz genauso so ist es.

Ja, aber um das beurteilen zu können, ob sich's überhaupt lohnt bräuchte ich eine Aussage, was meistens besser ist. Weil ich dann erst dazu bewegt werde mir über das eine oder andere Gedanken zu machen. Ich kann ja nicht für alle meine Abfragen hier jedesmal einen Thread eröffnen.

Struppi.

[Ilja]

Ja, aber um das beurteilen zu können, ob sich's überhaupt lohnt bräuchte ich eine Aussage, was meistens besser ist.

mir würde es ja schon ausreichen, wenn du das erst einmal nachvollziehen kannst, dass es eben von fall zu fall verschieden ist, dann kann man sich weiter unterhalten.

Ilja

[Struppi]

Ja, aber um das beurteilen zu können, ob sich's überhaupt lohnt bräuchte ich eine Aussage, was meistens besser ist.

mir würde es ja schon ausreichen, wenn du das erst einmal nachvollziehen kannst, dass es eben von fall zu fall verschieden ist, dann kann man sich weiter unterhalten.

Ich will mich ja nicht unterhalten, sondern einen allgemeinen Ratschlag. So lass ich es einfach wie es ist. Da keiner sagen will, was meistens besser ist. Da die jetzige Variante funktioniert, brauch ich das auch nicht zu hinterfragen.

Struppi.

[Ilja]

moin,

Ich will mich ja nicht unterhalten, sondern einen allgemeinen Ratschlag. So lass ich es einfach wie es ist. Da keiner sagen will, was meistens besser ist. Da die jetzige Variante funktioniert, brauch ich das auch nicht zu hinterfragen.

den allgemeinen und richtigen ratschlag hast du nun schon mehrfach bekommen, "es ist kontextabhängig". der gefällt dir offenbar nicht, ist deine sache, wie du damit umgehen willst, macht ihn aber nicht falsch.
wenn du auf einen bahnhof stehst und eigentlich nach flensburg willst, die meisten aber nach berlin fahren, dann weiß ich ja jetzt, wohin du fährst. und berlin ist ja auch eine schöne stadt, wer will schon nach flensburg....

Ilja

[Struppi]

wenn du auf einen bahnhof stehst und eigentlich nach flensburg willst, die meisten aber nach berlin fahren, dann weiß ich ja jetzt, wohin du fährst. und berlin ist ja auch eine schöne stadt, wer will schon nach flensburg....

Du gehst in deinen Beispielen immer davon aus, dass der Fragende weiß was er will. Wenn das so wäre, müßte er ja nicht fragen.

Mir geht es darum, dass man dem Fragenden den Ratschlag geben könnte, wenn er danach fragt, ob es billiger ist mit dem Auto oder der Eisenbahn fahren, wenn er nach Flensburg will.
Das hängt vom Kontext ab - ich habe das nie bestritten, aber du kapierst das Wort meistens oder seltens nicht, für dich heißt es anscheind immer und ausschließlich - aber meistens ist das Auto billiger, es sei denn er hat eine Bahncard und/oder er kriegt ein Billigticket und die Entfernung überschreitet eine gewisse Größe.

Aber als grundsätzliche Aussage ist "meistens das Auto" ausreichend und hilfreich.

Struppi.

[Ilja]

Aber als grundsätzliche Aussage ist "meistens das Auto" ausreichend und hilfreich.

und das wilst du ihm dann sagen, wenn er ganz konkret fragt, wie komme ich am günstigsten dort hin ?

Ilja

[Struppi]

Aber als grundsätzliche Aussage ist "meistens das Auto" ausreichend und hilfreich.

und das wilst du ihm dann sagen, wenn er ganz konkret fragt, wie komme ich am günstigsten dort hin ?

Jetzt erkennst du es. Dann muss man den konkreten Kontext ermitteln, weil das *meistens* eben bedeutet, dass es Fälle gibt, wo die Aussage nicht zutrifft.

Struppi.

[Ilja]

Jetzt erkennst du es. Dann muss man den konkreten Kontext ermitteln, weil das *meistens* eben bedeutet, dass es Fälle gibt, wo die Aussage nicht zutrifft.

nun wirst du wieder albern. wir hatten ja einen konkreten fall.

Ilja

[Struppi]

Jetzt erkennst du es. Dann muss man den konkreten Kontext ermitteln, weil das *meistens* eben bedeutet, dass es Fälle gibt, wo die Aussage nicht zutrifft.

nun wirst du wieder albern. wir hatten ja einen konkreten fall.

Wo?

Struppi.

[Ilja]

Wo?

select *
from vip_users, vipforum_users
where vip_users.user_name=vipforum_users.username

Ilja

[Struppi]

select *
from vip_users, vipforum_users
where vip_users.user_name=vipforum_users.username

und da kennst du jetzt den Kontext?
Dann scheinen wir unterscheidliche Vorstellungen des Begriffs Kontext zu haben.

Struppi.

[Ilja]

und da kennst du jetzt den Kontext?

du hast nicht richtig gelesen, ich sprach von einem konkreten fall, nicht kontext

Ilja

[Struppi]

und da kennst du jetzt den Kontext?

du hast nicht richtig gelesen, ich sprach von einem konkreten fall, nicht kontext

Dann hast du nicht richtig gelesen, ich schrieb dass der Kontext nötig ist um auf einen konkrete Frage zu antworten, was du mir hier schon gefühlte tausendmal gesagt hast.

In dem konkreten Fall, wissen wir den Kontext nicht und es läßt sich zu dem, was wir hier debatiert haben, nur eine allgemeine Aussage wie: "meistens ist es nicht sinnvoll.." treffen. Wobei die hier auch gar nicht an den OP gerichtet war, also nicht auf die konkrete Frage, sondern auf Antwort.

Struppi.

[Ilja]

ganz ehrlich Struppi, das wird mir zu blöd. du hast nicht nur vom kontext geschrieben, sondern auch von Fällen. und du mußt schon schauen, auf welcher deiner aussagen ich mich beziehe: "Dann muss man den konkreten Kontext ermitteln, weil das *meistens* eben bedeutet, dass es Fälle gibt, wo die Aussage nicht zutrifft." und darauf habe ich gesagt, wir haben einen konkreten fall. wenn wir uns schon nicht mal dort einig sind, dann werden wir es überhaupt nicht tun.

In dem konkreten Fall, wissen wir den Kontext nicht und es läßt sich zu dem, was wir hier debatiert haben, nur eine allgemeine Aussage wie: "meistens ist es nicht sinnvoll.." treffen.

es kann doch nicht so schwierig sein, bei einem konkreten fall den kontext zu ermitteln, sonfern er unbekannt ist und dann sagen ja, ich würde dir raten SELECT * zu benutzen oder nein, ich würde davon abraten. und wenn man den kontext nicht kennt, dann ist auch keine aussage möglich. schließlich geht es ja nicht um statistische umfragewerte, sondern um konkrete fälle.

Ilja

[Struppi]

In dem konkreten Fall, wissen wir den Kontext nicht und es läßt sich zu dem, was wir hier debatiert haben, nur eine allgemeine Aussage wie: "meistens ist es nicht sinnvoll.." treffen.

es kann doch nicht so schwierig sein, bei einem konkreten fall den kontext zu ermitteln, ..

Das sind ganz neue Wendungen, also ist es doch sinnvoll zu sagen meistens ist das verwenden von A oder B zuu empfehlen, da der Kontext ja ermittelbar ist? Das klang bisher immer anders.

Wobei es mir reichlich unbegreiflich ist, wie du es schaffst von DEINEN Beispielen, also in im letzten Fall den Bahnfahrten, wieder urplötzlich auf die ursprüngliche Frage im Thread zu kommen. Wobei diese noch nicht mal Auslöser für diese Diskussion war, sondern eine Antwort darauf.

sonfern er unbekannt ist und dann sagen ja, ich würde dir raten SELECT * zu benutzen oder nein, ich würde davon abraten.

und dann wieder ganz von vorne Anfangen, das ist echt unglaublich. Keiner! Niemand! Hat jemals in diesem Thread empfohlen zu sagen "benutze A oder B", es ging die ganze Zeit darum, dass in einem Fall wo MEISTENS - also in vielen Fällen!!!! Also NICHT immer!!!!! - etwas zu empfehlen ist, dass man das auch ausprechen darf, ohne gleich eine Grundsatzdiskussion über Aussnahmefälle auszulösen.

Ich habe das was ich meine, in diesem Posting in einem Beispiel ziemlich treffend dargestellt. Deine Reaktion darauf, plötzlich mit einen Rennwagen zu kommen, ist genau das was ich meine, dass ihr gerne Grundsatzdiskussionen führt, wenn es nicht nötig ist, aber dem gemeinen "Autofahrer" damit nicht weiterhelft. Weil für euch jeder Tipp ja Ausnahmesituationen nach sich zieht, die es nicht zulassen das ihr einen geben wollt (wobei in dem anderen von mir verlinktem Thread schriebst du "joins sind böse" - was ein guter Tipp ist, auch wenn die Begründung fehlt).

Struppi.

[Ilja]

ich schließe mich Deldfix an und beende hier die diskussion, bringt nichts mehr.

Ilja

[Struppi]

ich schließe mich Deldfix an und beende hier die diskussion, bringt nichts mehr.

Ist klar, wenn keines der Argumente die ich genannt habe überhaupt wahrgenommen wird, gibt es auch nichts zu diskutieren, wir haben uns ja mittlerweile mehrmals im Kreis gedreht.

Mir ging es letztlich auch lediglich darum (hatte ich dedlifix auch schon klar gemacht) meinen Standpunkt darzulegen, wie es sich für mich als Laie anfühlt und was ich für besser halte.

Da meine Meinung als Laie für euch aber nicht zählt, beharrt ihr leider auf eurem Standpunkt und eure Sichtweise als Experten. Was natürlich schade ist, da es vielleicht manchen helfen könnte, wenn ihr das nicht so eng sehen würdet.

Jetzt entwickeln sich eben immer diese Grundsatzdebatten, wo die Fachleute sich streiten, welche Ausnahmesituation die Regel nicht allgemeinegültig macht und somit keine Regel ist. Und hinterher ist der Laie nur verwirrt und weiß u.U. weniger als vorher.

Struppi.

[dedlfix]

Hi!

Eigentlich wollte ich ja nichts mehr sagen, aber wenn du meinen Standpunkt nicht richtig zusammenfasst, möchte ich ihn nochmal klarstellen.

Da meine Meinung als Laie für euch aber nicht zählt, beharrt ihr leider auf eurem Standpunkt und eure Sichtweise als Experten. Was natürlich schade ist, da es vielleicht manchen helfen könnte, wenn ihr das nicht so eng sehen würdet.

Mir geht es darum, dass es nicht nur manchen meistens hilft sondern allen immer. Und da kann man eben nicht mehr nach der Statistik zu gehen sondern muss individuell entscheiden. Meine Engstirnigkeit gilt hier dem Individuum. Dessen Problem muss gelöst werden, nicht der Statistik Genüge getan werden.

Jetzt entwickeln sich eben immer diese Grundsatzdebatten, wo die Fachleute sich streiten, welche Ausnahmesituation die Regel nicht allgemeinegültig macht und somit keine Regel ist. Und hinterher ist der Laie nur verwirrt und weiß u.U. weniger als vorher.

Deswegen will ich ihn ja nicht mit vereinfacht eingeschränkten Regeln füttern sondern mit grundlegendem Wissen. Dass dir und anderen das zu viel ist, kann ich nicht ändern. Komplexe Themen werden durch Wissensverweigerung jedenfalls nicht einfacher.

Lo!

[Struppi]

Deswegen will ich ihn ja nicht mit vereinfacht eingeschränkten Regeln füttern sondern mit grundlegendem Wissen. Dass dir und anderen das zu viel ist, kann ich nicht ändern. Komplexe Themen werden durch Wissensverweigerung jedenfalls nicht einfacher.

Mir ist es nicht zuviel, sondern mir fällt es einfacher die Informationen anders zu besorgen, als in Debatten, wo jeder seine Meinung vertritt.  Ich denke, dass das den meisten so geht.

Und ich hab das sicher schon gesagt, es geht darum eine Grundlage zu bekommen, um sich informieren zu können. Wenn nun tagelang darüber gestritten wird, in welchen Ausnahmesituationen nun die Regel nicht gilt, erschwert das unnötigerweise die Aufnahme der Information.

Struppi.

[dedlfix]

Hi!

Deswegen will ich ihn ja nicht mit vereinfacht eingeschränkten Regeln füttern sondern mit grundlegendem Wissen. Dass dir und anderen das zu viel ist, kann ich nicht ändern. Komplexe Themen werden durch Wissensverweigerung jedenfalls nicht einfacher.
Mir ist es nicht zuviel, sondern mir fällt es einfacher die Informationen anders zu besorgen, als in Debatten, wo jeder seine Meinung vertritt.  Ich denke, dass das den meisten so geht.

Und wie würdest du das dann ändern wollen? Wenn jemand eine Meinung vertritt, die jemand anders als unzureichend oder unangemessen findet, was anderes soll da passieren als dass sich eine Debatte darüber entspannt?

Ich sehe auch, dass viele dann eingeschüchtert nichts mehr sagen. Und das sehe ich dann aber auch als ihren Fehler an - wenn sie sich nicht zu Wort melden, kann man nicht weiter auf sie eingehen.

Lo!

[Struppi]

Und wie würdest du das dann ändern wollen? Wenn jemand eine Meinung vertritt, die jemand anders als unzureichend oder unangemessen findet, was anderes soll da passieren als dass sich eine Debatte darüber entspannt?

Je nach Kontext ;-)

Es gibt sicher Fälle, in denen pauschale Aussagen ein Problem sein können, aber ich denke halt, dass eine gewisse Menge an Grundlagenwissen, bzw. auch ein Interesse daran, das Thema zu Hinterfragen meistens vorhanden ist und wenn nicht, sind auch ausufernde Erklärungen nicht hilfreich.

Du kennst das vermutlich auch, dass man sich die Mühe macht und ellenlange Erklärungen formuliert und dann kommt keine Reaktion mehr. War das jetzt informativ oder nicht? Man weiß es oft nicht.

Ich sehe auch, dass viele dann eingeschüchtert nichts mehr sagen. Und das sehe ich dann aber auch als ihren Fehler an - wenn sie sich nicht zu Wort melden, kann man nicht weiter auf sie eingehen.

Das Problem, dass ich seh, dass diese Grundsatzdebatten dem OP vermutlich oft zu weit abdriften. Es ist ja nicht so, dass ich nicht diese Threads kenne, wo man bis in's Kleinste ein Thema seziert und analysiert und der, der den Thread aufgemacht hat, sieht man nie wieder.

Und die andere Seite ist, dass es, vor allem wenn es nur um Nebensächlichkeiten geht, für alle erst einmal einfacher ist, wenn nur ein Hinweis gegeben wird. Der Antwortet muss weniger formulieren und der Fragende sieht den einen Punkt, den er vorher evtl. nicht beachtet hat.

Aber ich betrachte das ganze auch Bidirektional, je einfacher die Fragestellung, umso einfacher fällt meine Antwort aus.

Naja, wo ich letztlich hinaus will, ist das eine gewisse Pauschalsierung durchaus hilfreich sein kann, aber natürlich in einzelnen Fällen nicht ausreichend sein muss. Die Frage oder der Streit hier, ob man eine solche Pauschalisierung immer vermeiden muss oder sollte. Oder ob auch mal eine Pauschalsierung stehen bleiben kann ohne dass eine Debatte über Ausnahmefälle geführt werden muss?
Da stehe ich auf den Standpunkt, dass nicht jedes Detail einer Aussage ausdiskutiert werden muss.

Struppi.

[dedlfix]

Hi!

Nach deiner Logik, müßte ich - wenn ich alle meine Abfragen in den Anwendungen darauf überprüfen wollte - dir alle hunderte Joins zeigen, damit du mir sagen kannst, in welchem Kontext ich mich bewege und ob im Einzelfall ein join oder ein subselect besser ist.

Nach meiner Logik müsstest du wissen, wie sich beide Verfahren bei welcher Datenlage verhalten. Es kann ja durchaus sein, dass je nach Anzahl der Datensätze und der Kardinalität[*] des Auswahlkriteriums sich die Laufzeiten unterschiedlich verhalten. In so einem Fall kannst du nur die zu erwartenden Daten einzuschätzen versuchen und dann die Schlussfolgerungen ziehen. Und es kann sein, dass im Laufe der Zeit die Datenlage anders wird und die einstmals optimale Abfrage keine solche mehr ist. Da hast du dann eine nach statistischen Erhebungen "meistens" schnelle Abfrage, die trotzdem wie eine Schnecke kriecht. Irgendwann helfen dir keine einfachen Regeln mehr und du brauchst das Hintergrundwissen sowie Kenntnisse beim Umgang mit den Profiler-Werkzeugen, um dir die genaue Sachlage anzuschauen.

[*] Je häufiger ein Wert vorkommt, desto weniger nützt ein Index, weil dieser dann die betroffene Datenmenge nicht genug einschränken kann. Wenn beispielsweise nur die Werte 0 und 1 vorkommen (angenommen zu je 50%), lohnt auf der Spalte kein Index, weil sowieso die Hälfte aller Datensätze in der Ergebnismenge sein muss und vielleicht ein full table scan diese Menge schneller liefert als das zusätzliche Lesen eines Index. (Nagel mich jetzt nicht auf dieser speziellen Aussage fest, ich bin kein Datenbankexperte. Aber es gibt solche Fälle, wo Indexe wegen vom Query-Optimierer vermuteter Ineffizienz ignoriert werden.)

Lo!

[Struppi]

Irgendwann helfen dir keine einfachen Regeln mehr und du brauchst das Hintergrundwissen sowie Kenntnisse beim Umgang mit den Profiler-Werkzeugen, um dir die genaue Sachlage anzuschauen.

Ich bestreite ja auch nicht, dass man Hintergrundwissen braucht. Im gegenteil ich behaupte sogar, das man schon ein gewisses Wissen braucht um überhaupt eine Frage zu formulieren.

Also gehe ich davon aus, dass der die Frage stellt Hintergrundwissen hat, mit dem er in der Lage ist, mit Hilfe einer klaren einfachen Regel, sich für seinen Anwendungsfall das Optimale zu erarbeiten.

Wenn das nicht der Fall ist, würde ich zumindest, im konkreten Fall nachfragen, z.b. wenn ich nicht weiß welche Werkzeuge ich einsetzen kann um das zu ermitteln. Dafür ist ja ein Forum da.

Struppi.

[dedlfix]

Hi!

Also gehe ich davon aus, dass der die Frage stellt Hintergrundwissen hat, mit dem er in der Lage ist, mit Hilfe einer klaren einfachen Regel, sich für seinen Anwendungsfall das Optimale zu erarbeiten.

Das ist der nicht zu überbrückende Unterschied zwischen uns beiden. Ich nehme eine solche Annahme nicht an, sondern versuche den Wissensstand des Fragenden anhand der gegebenen Informationen herauszufinden.

Lo!

[Ilja]

moin,

[*] Je häufiger ein Wert vorkommt, desto weniger nützt ein Index, weil dieser dann die betroffene Datenmenge nicht genug einschränken kann. Wenn beispielsweise nur die Werte 0 und 1 vorkommen (angenommen zu je 50%), lohnt auf der Spalte kein Index, weil sowieso die Hälfte aller Datensätze in der Ergebnismenge sein muss und vielleicht ein full table scan diese Menge schneller liefert als das zusätzliche Lesen eines Index.

man sagt eine b-tree index ist nur bei ca. 10% datenmenge noch effektiv. allerdings gibt es gerade für solche fälle mit 0 und 1 einen anderen index typ, nämlich einen bitmap index.

Ilja

[dedlfix]

Hi!

Welche Risiken sollen denn dahinter stecken, dass ich nicht alle Felder selektiere?

Müssen es unbedingt Risiken sein? Das Risiko besteht darin, dass man sich zu wenig Gedanken macht. In erster Linie hat eine Vorgehensweise Eigenschaften. Ob diese positiv oder negativ sind ist anwendungsfallabhängig, unabhängig davon ob die Statistik den einen oder anderen Anwendungsfall bevorzugt.

Der einzige Risikofaktor ist doch der, das nicht alle Felder in der Abfrage vorkommen, aber das ist völlig logisch.

Ja, das merkst du in der Regel auch ziemlich schnell, weil in der Ausgabe was fehlt. Merkst du genauso schnell, wenn du beim Verringern der Ausgabemenge die Query nicht angepasst hast, dass du dann zu viele Spalten abfragst, was ja ganz, ganz schreckliche Auswirkungen auf die Performance hat?

Ich für meinen Teil, hätte diese Information gerne viel früher gelesen, denn in meinen alten Anwendungen wimmelt es nur so von select *, ich wurde nie darauf hingewiesen. z.b. hier.

Welche Auswirkungen hat es denn in deinen Fällen konkret gehabt? Wieviel Daten hast du eingespart und wieviel Pflegeaufwand hast du generiert? Diese Aussage kommt mir so vor, als ob die anderen schuld waren, dass sie dir das nicht gesagt haben. Die SELECT-*-Predigten sind nur unwesentlich jünger als SQL selbst. Leider ist auch die Vorgehensweise recht verbreitet, Anfängern oft zu einfach in ein Thema einzuführen und weitergehendes Wissen als Tipps und Tricks zu verkaufen.

Wie hat sich eigentlich deine Arbeitsweise seit der SELECT-*-Aufklärung geändert? Vermeidest du einfach nur seine Anwendung oder denkst du fallabhängig darüber nach, welche Vor- und Nachteile dir der Verzicht darauf bringt?

Wie gesagt, ich sehe diese Diskussion als Laie und mir bringt die Information das alle Felder zu selektieren schlecht ist wesentlich mehr, als eine Diskussion darüber, wann es nicht der Fall ist.

Womit wir wieder am Anfang wären: Es ist nicht prinzipiell schlecht, alle Felder zu selektieren - nicht in jedem Fall. Als Erfahrener sehe ich, dass es besser ist, Wissen in neutraler Form zu lernen statt (vereinfachte) Regeln zu lernen, auch wenn überwiegend der See einen Meter tief ist. Letzteres ist eine nette Zusatzinformation, die aber nicht den Blick für die Ausnahmen trüben darf.

Die Aussage gegenüber dem Laien sollte nicht sein: "XY ist (meistens) Mist" sondern er muss herangeführt werden zur eigenständigen Klärung der Frage: Ist XY in einem speziellen Fall a) angemessen, b) ungeeignet oder c) die Auswirkungen nicht relevant?

Lo!

[Struppi]

Welche Risiken sollen denn dahinter stecken, dass ich nicht alle Felder selektiere?

Müssen es unbedingt Risiken sein?

Der Begriff kam von Ilja

Der einzige Risikofaktor ist doch der, das nicht alle Felder in der Abfrage vorkommen, aber das ist völlig logisch.

Ja, das merkst du in der Regel auch ziemlich schnell, weil in der Ausgabe was fehlt. Merkst du genauso schnell, wenn du beim Verringern der Ausgabemenge die Query nicht angepasst hast, dass du dann zu viele Spalten abfragst, was ja ganz, ganz schreckliche Auswirkungen auf die Performance hat?

Ja, weil ich in den meisten Fällen ein Objekt benutze, dass explizit alle Felder definert. D.h. ich krieg bei diesen Abfragen wenn sie zuviel Felder enthalten, direkt eine Fehlermeldung.

Und was die Performance angeht bin ich über jden Tipp dankbar. Mir ist mein Paket schon gesperrt wurde, da die Seite extrem schwankende Zugriffszahlen hat und erst nach intensiver Nachbearbeitung der SQL Abfragen läuft sie stabil (das war dann die Möglichkeit für mich soviel wie möglich von Explain zu lernen, ausserdem wurden die komplexen Abfragen gecached).

Ich für meinen Teil, hätte diese Information gerne viel früher gelesen, denn in meinen alten Anwendungen wimmelt es nur so von select *, ich wurde nie darauf hingewiesen. z.b. hier.

Welche Auswirkungen hat es denn in deinen Fällen konkret gehabt? Wieviel Daten hast du eingespart und wieviel Pflegeaufwand hast du generiert?

Das läßt sich in einer komplexen Anwendung kaum bestimmen. Ich entnehme aber deinen Ausführungen, dass du es für kaum nennenswert hälst?

Diese Aussage kommt mir so vor, als ob die anderen schuld waren, dass sie dir das nicht gesagt haben. Die SELECT-*-Predigten sind nur unwesentlich jünger als SQL selbst. Leider ist auch die Vorgehensweise recht verbreitet, Anfängern oft zu einfach in ein Thema einzuführen und weitergehendes Wissen als Tipps und Tricks zu verkaufen.

Ich geb doch niemanden die Schuld an irgendwas. Sondern sage nur, dass mir dieser Tipp geholfen hätte, wenn ich ihn früher aufgeschnappt hätte und ich mich wundere, dass und warum er so kontrovers hier diskutiert wird, ohne das ich erkennen kann, was ich nun davon habe, wenn ich alle Felder selektiere, anstatt select * zu vermieden wo immer es geht.

Wie gesagt, ich sehe diese Diskussion als Laie und mir bringt die Information das alle Felder zu selektieren schlecht ist wesentlich mehr, als eine Diskussion darüber, wann es nicht der Fall ist.

Womit wir wieder am Anfang wären: Es ist nicht prinzipiell schlecht, alle Felder zu selektieren - nicht in jedem Fall. Als Erfahrener sehe ich, dass es besser ist, Wissen in neutraler Form zu lernen statt (vereinfachte) Regeln zu lernen, ..

Dann bist du sicher ein Leuchturm, was das aneignen von Wissen angeht. Ich kann das so nicht.

Ich glaube auch nicht das das viele können. Wenn man sich auf etwas spezialisiert, ist es sicher einfacher, sich umfassend und allwissend über alle Aspekten eines Bereiches zu informieren.

Da es aber nötig ist, wenn man im Webbereich arbeitet, von allen etwas zu Wissen, grenzt das an eine Unmöglichkeit. Du brauchst, um eine Seite zu betreiben, das Wissen von mehreren Programmiersprachen, Auszeichnungssprache, Serverkonfiguration, Datenbanken, daneben die vielen kleineren Sachen, wie das Auswerten von Logfiles, Bildbearbeitung und dazu kommen ständig neue Änderungen und Erweiterungen, die sich die Nutzer wünschen.

Insofern sehe ich das Lernen, wie du es dir vorstellst als utopisch an. Und ich glaube dass es vielen, die hier Fragen und manchen die hier antworten nicht anders geht. Es ist wesentlicher einfacher mit klaren Regeln zu arbeiten, als sich über jede Regel Gedanken machen zu müssen.

Die Aussage gegenüber dem Laien sollte nicht sein: "XY ist (meistens) Mist" sondern er muss herangeführt werden zur eigenständigen Klärung der Frage: Ist XY in einem speziellen Fall a) angemessen, b) ungeeignet oder c) die Auswirkungen nicht relevant?

In einem Kurs an der Uni magst du Recht haben, aber in der Praxis sieht das anders aus, wie man hier jeden Tag hundertfach sieht. Von denen die hier Fragen, ist vielleicht einer im halben Jahr wirklich bereit und willig intensiv etwas zu lernen, die meisten suchen eine Lösung im Rahmen ihres Wissens.

Struppi.

[dedlfix]

Hi!

Welche Auswirkungen hat es denn in deinen Fällen konkret gehabt? Wieviel Daten hast du eingespart und wieviel Pflegeaufwand hast du generiert?
Das läßt sich in einer komplexen Anwendung kaum bestimmen. Ich entnehme aber deinen Ausführungen, dass du es für kaum nennenswert hälst?

Das war jetzt wieder ernst gemeint. (Nicht nur) ich halte es für wichtig, nicht ins Blaue hinein Verbesserungen zu versuchen. Sie müssen nachvollziehbare Änderungen bringen und sollten den Wartungsaufwand nicht unangemessen hoch treiben.

Ich geb doch niemanden die Schuld an irgendwas. Sondern sage nur, dass mir dieser Tipp geholfen hätte, wenn ich ihn früher aufgeschnappt hätte und ich mich wundere, dass und warum er so kontrovers hier diskutiert wird, ohne das ich erkennen kann, was ich nun davon habe, wenn ich alle Felder selektiere, anstatt select * zu vermieden wo immer es geht.

Nicht wo immer es geht, sondern wo immer es sinnvoll ist. Das ist der entscheidende Unterschied. Und das ist mein Anliegen, sinnvolle Werkzeugverwendung statt unreflektierte Regelanwendung.

Wenn man sich auf etwas spezialisiert, ist es sicher einfacher, sich umfassend und allwissend über alle Aspekten eines Bereiches zu informieren.

Oder man wird zum Fachidioten. Das versuche ich zu vermeiden, indem ich mich bemühe, die Dinge von allen Seiten aus zu betrachten. Auch dann, wenn ich mit der Gegenseite nicht konform gehe, muss ich deren Argumente kennen, um auch meine Lage besser einschätzen zu können.

Da es aber nötig ist, wenn man im Webbereich arbeitet, von allen etwas zu Wissen, grenzt das an eine Unmöglichkeit. Du brauchst, um eine Seite zu betreiben, das Wissen von mehreren Programmiersprachen, Auszeichnungssprache, Serverkonfiguration, Datenbanken, daneben die vielen kleineren Sachen, wie das Auswerten von Logfiles, Bildbearbeitung und dazu kommen ständig neue Änderungen und Erweiterungen, die sich die Nutzer wünschen.

Komplexe Themen erfordern nun mal komplexes Wissen, wenn man es richtig machen will. Das bekommt man nicht durch Tutorial-Lesen sondern vor allem durch eigene Anstrengungen - und viel investierte Zeit.

Insofern sehe ich das Lernen, wie du es dir vorstellst als utopisch an. Und ich glaube dass es vielen, die hier Fragen und manchen die hier antworten nicht anders geht. Es ist wesentlicher einfacher mit klaren Regeln zu arbeiten, als sich über jede Regel Gedanken machen zu müssen.

Das ist auch in meinen Augen verständlich - aber nicht in Stein gemeißelt. Man kann wenigstens versuchen, die Blickschärfung anzuregen. Regeln können vor allem bei komplexten Dingen nur dann einfach sein, wenn sie zwar viele Fälle abdecken, aber die Ausnahmen nicht berücksichtigen. Deswegen sollen ja nach meinen Vorstellungen nicht die Regeln das Maß der Dinge werden sondern das Wissen, wie etwas funktioniert. "Immer mysql_real_escape_string() anwenden" ist beispielsweise eine einfache Regel, und sie ist auf diese Weise vereinfacht nicht richtig, weil sie die Ausnahmen unberücksichtigt lässt und damit einige Sicherheitslücken bestehenbleiben. "Bei Strings mysql_real_escape_string() anwenden" erhöht die Komplexität der Regel schon um eine Bedingung. Aber dann fehlen immer noch die Fälle für Zahlen, Datumsangaben, Konstanten (wie NULL), unveränderliche Strings und so weiter. Die Regel versprach Einfachheit - und hat es nicht halten können. "Kontextgerechte Behandlung" ist auch eine einfache, diesmal aber allumfasende Regel. Sie ist jedoch so unspezifisch, dass man damit ohne weiteres Wissen nicht viel anfangen kann.

Was nützen dann die Regeln, wenn sie Lücken lassen, die sie zu stopfen versprechen?

Die Aussage gegenüber dem Laien sollte nicht sein: "XY ist (meistens) Mist" sondern er muss herangeführt werden zur eigenständigen Klärung der Frage: Ist XY in einem speziellen Fall a) angemessen, b) ungeeignet oder c) die Auswirkungen nicht relevant?
In einem Kurs an der Uni magst du Recht haben, aber in der Praxis sieht das anders aus, wie man hier jeden Tag hundertfach sieht.

Ich habe keine Ahnung, wie Uni-Kurse arbeiten. Aber ich kann mir gut vorstellen, dass auch die Uni mehr oder weniger nur Grundlagenwissen lehren kann und die Methodik wie man sich selbst das fehlende Wissen beschafft. Zu wissen, wie irgendwas in der Theorie geht, ist schön und gut, da fehlt nur die Praxis. Reines Wissen zu lernen fällt mir nicht leicht, und das wird mit zunehmenden Alter nicht besser. Ich verbrauche viel Zeit mit Ausprobieren und dem ungezwungenen Umgang, gerade auch angeregt durch Forumsprobleme. Erfahrung erfordert Anstrengung.

Von denen die hier Fragen, ist vielleicht einer im halben Jahr wirklich bereit und willig intensiv etwas zu lernen, die meisten suchen eine Lösung im Rahmen ihres Wissens.

Einfach gesagt wäre das ihr Problem. Weitergedacht ist es aber auch mein Problem, weil durch ihre unsicheren Systeme auch mein Leben beeinträchtigt wird. Ich bekomme Spam nicht weil meine Systeme Lücken haben, sondern weil irgendwer anders seins nicht abgesichert hat. Wer das nicht einsehen will oder sich hinter seiner Lernunfähigkeit versteckt, ist auch irgendwie egoistisch. Natürlich mach ich mir keine Illusionen, das ich durch meine Hinweise hier die Welt verbessern kann, aber ist das ein Grund nicht wenigstens ein kleines bisschen Aufklärung zu betreiben?

Lo!

[Struppi]

das ist doch ein widerpsruch, du benutzt auf der einen seiten wörter wie "selten", "häufig", etc. und auf der andere seite pauschalisiert du. SELECT * ist nun mal fallabhängig. und da hilft auch nicht das argument gegenüber anfänger. es macht doch keinen sinn, denen erst beibringen zu wohlen, benutze SELECT * nie im produktiveinsatz und ihnen dann später zu erklären, dass dies nur für anfänger gilt und dann wenn sie mehr wissen, erzählt man ihnen die ganze wahrheit.

Das tut doch keiner.

Es wurde hier ein Beispiel (nicht vom OP) mit select * gebracht und EKKI hat die Einwände die dagegen sprechen können eingeschoben.

Es gab hier in dem Thread also nie die von euch beiden herbei geredete Einseitigkeit, es gab von Anfang an beides. Also genau das was ihr wollt. eine Kontroverse über die Fragstellung

Und ich muss sagen, dass ich als DB Laie mehr von dem Einwand gegen Select * gelernt habe, als das ich die Argumente, die anscheinend dem Wort seltenst entgegen stehen, nachvollziehen kann. Ich habe noch nie Views eingesetzt und soweit ich diese Begreife auch keinen Verwendungszweck gesehen und das man sich bei einer Adhoc Abfrage alle Felder anzeigen läßt, ist eine Selbstverständlichkeit.

Ich weiß nicht wo ihr hier Lehrbedarf seht, wenn es zwei seltene Fälle gibt, die für den Einsatz sprechen, die EKKI dummerweise nicht erwähnt hat, aber ansonsten es doch stimmt, dass der Einsatz von select * bedacht werden soll.

Struppi.