Blätter funktion erweitern

[Zvoni]

@Zvoni Du schriebst:

und

Dann hast Du sicher auch Messergebnisse in der Schublade, aus denen hervorgeht, in welchem Umfang das Angeben der Spalten gegenüber SELECT * die Performance verbessert?

Nur „subjektive“ da ich kein dba bin, und demzufolge nicht die admin-Werkzeuge habe.
meine queries mache ich mit nem kleinen Client-Programm oder aus VBA-code heraus via ODBC-Verbindung für die reports die ich generiere.

seit ich angefangen habe, auf explizite SELECTs umzustellen, habe ich das Feedback „deutlich/merkbar schneller“ von so ziemlich allen Anwendern erhalten.

und meine queries haben schon mal 20 joins (INNER/LEFT) mit keine ahnung wievielen Aggregats- und Window-Funktionen

das problem bei uns ist das Design der Datenbank (IBM DB2 auf einer iSeries).
kein einziger Primärschlüssel (auch keine Fremdschlüssel) im „klassischen Sinne„, sondern Redundanz von Feldern.
Und die Tabellen bei uns haben mal schnell 50-60 Spalten (Oder auch deutlich mehr).

deshalb bin ich mittlerweile zu einem Fürsprecher echter SELECTs geworden.

Selbstverständlich benutze ich auch mal ein SELECT * FROM wenn ich eine bestimmte Information suche, aber dann auch nur mit einer rigorosen WHERE-Klausel.
Auch dieses SELECT wird dann sehr früh zu einem explizitem SELECT umgebaut

EDIT: Zur Info.
Hab mal Spasseshalber mein letztes Query eben laufen lassen.
16 Joins lt. Zählung (unter anderem ineinander verschachtelt)
44 Ausgabe-Spalten
Quelle hat mehrere Millionen Datensätze (verteilt über die Tabellen)
Ergebnis: 700 Sätze (korrekt!)
Dauer (nicht lokal sondern per WAN): ca. 1 Minute

 

[Sempervivum]

seit ich angefangen habe, auf explizite SELECTs umzustellen, habe ich das Feedback „deutlich/merkbar schneller“ von so ziemlich allen Anwendern erhalten.

Das ist ziemlich vage und, wie Du selbst schreibst, "subjektiv". Ich bevorzuge dem gegenüber die Gepflogenheiten in der Wissenschaft wo objektive Messungen und Versuchsergebnisse einen hohen Stellenwert haben.

Hab mal Spasseshalber mein letztes Query eben laufen lassen.
16 Joins lt. Zählung (unter anderem ineinander verschachtelt)
44 Ausgabe-Spalten
Quelle hat mehrere Millionen Datensätze (verteilt über die Tabellen)
Ergebnis: 700 Sätze (korrekt!)
Dauer (nicht lokal sondern per WAN): ca. 1 Minute

Das ist wohl gewaltig aber ich kann keinen Zusammenhang zum Thema "explizite Selects" erkennen. Außerdem wundert es mich, dass Du auf der einen Seite mit solch komplexen Abfragen und gewaltigen Datenmengen hantierst, auf der anderen aber keine Werkzeuge an der Hand hast, um objektiv zu überprüfen, wie effizient diese sind und in welchem Umfang eine Optimierung Erfolg hat.

 

[Zvoni]

Das ist ziemlich vage und, wie Du selbst schreibst, "subjektiv". Ich bevorzuge dem gegenüber die Gepflogenheiten in der Wissenschaft wo objektive Messungen und Versuchsergebnisse einen hohen Stellenwert haben.


Das ist wohl gewaltig aber ich kann keinen Zusammenhang zum Thema "explizite Selects" erkennen. Außerdem wundert es mich, dass Du auf der einen Seite mit solch komplexen Abfragen und gewaltigen Datenmengen hantierst, auf der anderen aber keine Werkzeuge an der Hand hast, um objektiv zu überprüfen, wie effizient diese sind und in welchem Umfang eine Optimierung Erfolg hat.

Weil ich eben kein DBA in der Firma bin, sondern eben auch nur "User" (aber eben halt einer der die "Hintertüren" kennt)
OK, stimmt. Kein Bezug zu explizite SELECTS.
Wenn ich o.g. Query mit SELECT * mache (wo es geht), dann geht das Query mal bequem auf jenseits von 5 Minuten.
Bei uns kommt erschwerend eben noch das WAN (anstatt LAN) hinzu, auf der anderen Seite ist es über ein WAN aber halt deutlich "spürbarer", da wir halt dann doch nicht die 1GBit-Leitung pro User wie im LAN haben.

Und ich stimme dir 100% zu, was das "wissenschaftliche Prinzip" betrifft