antwort: ziemlich schnell, schneller als ein Mensch bemerken kann.
Die Geschwindigkeit hängt v.a. an der abgerufenen Datenmenge.

aber Frage - was ist ein Q & A ?

paddy91952 schrieb:

Wie lange dauert

Falls Du die Länge des Vorganges tatsächlich ermitteln willst, sieh Dir mal die Klasse StopWatch an.
Vor dem Prozess starten, danach anhalten und auslesen.

ErfinderDesRades schrieb:

Q & A

Questions & Answers. Häufig gestellte Fragen und Antworten dazu.

@paddy91952 Wenn id der Primärschlüssel ist, oder einen Index hat, geht sowas ruckzuck. Müsste die DB jetzt aber nen Tablescan durchführen (also jeden Datensatz einzeln angucken) dann kann auch sowas realtiv lange dauern.
In jedem Fall stimmt aber,

ErfinderDesRades schrieb:

Die Geschwindigkeit hängt v.a. an der abgerufenen Datenmenge.

rufst du mit deinem Select 2 Millionen Datensätze ab, so kann es durchaus eine Weile brauchen, bis eine Antwort kommt. Da sind dann gute Indizes in der Datenbank und eventuell Paging in deiner Anwendung gefragt, um die Wartezeiten zu minimieren. Aber auch die Verwendete Festplatte auf der die Datenbank liegt, kann ein bremsender Faktor sein (und das bereits bei tausenden Datensätzen).

40k Datensätze sind wenig. Und beachte grundsätzlich das was @EaranMaleasi. Zusätzlich ist es häufig auch schlecht, ein Select * zu verwenden. Damit verbaut man sich den Weg sogenannte "Covering Indizes" zu Nutze zu machen. Man sollte bei Abfragen eigentlich fast immer genau angeben, welche Spalten man möchte (auch aus Gründen der Wartbarkeit)

Mono schrieb:

aus Gründen der Wartbarkeit

scheint mir Select * einfacher.
Weil wenn ich Spalten ändere, zufüge, lösche, muss ich bei Select * nix nacharbeiten (es warten also)
Kannst du "Covered Indizees" noch näher erläutern, kurz - (wär mir recht, wenns ohne Links auf seitenlange englische Fachartikel ginge - ich will ja nur das Prinzip grundsätzlich verstehen)

---

"Q + A" - das heisst doch "FAQ" - (Frequently Asked Question)
/klugscheiss

Nein select * ist nicht zwingend einfacher bezüglich der Wartbarkeit. Kommt drauf an, was gewartet wird.
Wenn es um ORM's geht mag Select * vielleicht einfacher sein. Aber wenn es um die Datenbank selbst geht nicht. (In StoredProcedures/Views zB kann eine Änderung einer Tabellestruktur dann ggf. zu Problemen führen, die man nicht so schnell findet)

Ein weiterer Nachteil ist oft Overhead an Informationen. Vor allem bei Joins und dann bei Übertragung übers Netzwerk. Und ich denke auch für Datasets gilt, am besten nur die Daten beinhalten die man wirklich benötigt.

Ein Covering Index ist kurz gesagt ein Index, der neben dem Primärschlüssel angelegt wird und mehrere Spalten mit Daten beinhaltet Wenn dann eine Abfrage kommt, können die Daten direkt aus dem Index gelesen werden und die Tabelle selber wird nimmer angefasst. Das ist natürlich nur dann sinnvoll, wenn eine große Tabelle mit 30 Spalten und zig Datensätzen häufiger eben eigentlich nur 4 Informationen liefern muss. Dann erstellt man über die 4 Spalten einen solchen Index und hat dadurch erheblich Performancevorteile was das Scannen der Daten angeht. Nachteil ist logischerweise etwas schlechtere Performance bei Delete/Update/Insert und etwas mehr Speicherbedarf. Der Coveringindex funktioniert aber nur wenn eben genau die 4 Spalten abgefragt werden (oder weniger) und macht logischerweise keinen Sinn wenn alle Spalten inkludiert sind.

Das ist aber alles eher bei wirklich größeren Datenmengen relevant.

vielen Dank!

Mono schrieb:

select * ... Vor allem bei Joins...

jo, daran habich garnet gedacht - weil ich verwende so gut wie nie Joins, bzw. selecte von einem Join nur eine Tabelle
Weil Joins, die mehrere Tabellen zusammenrühren erzeugen Tabellen, die ich nicht mehr rückspeichern kann.
Ich frage Tabellen immer getrennt, und als rückspeicherbare Komplett-Einheiten ab, und bastel dann im Gui ggfs einen "Joining-View", der ebenfalls aus beiden Tabellen die verknüpften Daten präsentiert, aber da kann ich auch Änderungen vornehmen und rückspeichern.
Das getrennte Laden sind dann 2 Abfragen, aber da die ParentTabelle nur sehr wenige Datensätze liefert, und die ChildTabelle ohne die zu-gejointen Spalten "schlank" ist, ist das auch ziemlich effizient. Also meine select * sehen auch bei Joins so aus:
weil ersteres kann ich rückspeichern, letzteres nicht.

---

hmm - ganz schön offtopic, aber andererseits berührts tatsächlich die Frage nach Db-Performance.
Könnte man überlegen, ob der Thread nicht doch in den Tuts richtig untergebracht wäre - mit Titel: "[FAQ]: Db-Performance" oderso

Finde es eigentlich nicht sehr Offtopic. Die Frage kann man ja gar nicht genau beantworten. Man kann nur alle möglichen Faktoren nennen, die einen Einfluss auf die Antwort haben

Und genau das was du nicht machst, sollte man auch vermeiden. Dort kann und wird der Overhead natürlich riesig, vorallem wenn mehrere Tabellen mit vielen Spalten gejoint werden.