Wechle Abfrage ist besser?

MS SQL Server 2005

Hallo ihr Freunde der leichten Unterhaltung 🙂

Ich habe da mal ne Frage die nur am Rande mit C# zu tun hat, bitte nicht übel nehmen!
Welche Abfrage ist schneller besser u.s.w.

1.
select ... from a left join b on a.id_B = b.id left join c on a.id_C = c.id
where
a.id = 1;

oder

2.
select ... from a, b, c
where
a.id_B = b.id and
a.id_C = c.id and
a.id = 1;

Danke schon mal
Markus

Hallo Reverent,

Normalerweise wird einem immer gesagt dass man die joins verwenden soll, weil es angeblich der elegantere Weg ist.

Erst bei riesigen Datenbanken wird man Unterschiede zwischen den beiden Abfragen erkennen können, aber welche wirklich schneller ist kann ich dir auch nicht sagen.

Mach doch mal selbst einen Versuch welche der beiden Abfragen schneller ist, indem du einfach alle notwendigen Tabellen mit riesigen Datenmengen füllst und anschließend die Zeit misst die für die Abfrage benötigt wird.

Gruss
MichlG

Danke erstmal michlG,
aber so große Datenmengen > 1000 oder so werden das nicht werden.
Ich habe da noch eine Frage:
Was ist System schonender,
die Tabellen in DataSet's zu speichern oder sich die Mühe machen die Tabellen auf eigene Objekte zu mappen?
z.B.
Tabelle Kunde
id
name
str
...

class Kunde
{
 private Guid id;
 private string name;
 private string str;
 ...
}

und so Objekte von den einzelnen Kunden zu haben.
Danke schon mal.
Markus

Hallo Reverent,

früher waren die abfragen mit Join schneller aber mittlerweile sollte das bei den meisten Datenbanken egal sein.

mfg

Falls du es etwas genauer wissen willst...

Geh mal ins Microsoft SQL Server Management Studio (Express).

Starte dort eine 'Neue Abfrage' für deine Datenbank.

Im Abfragefenster gibst du deine zu vergleichenden Queries an und anschliessend wählst du 'Geschätzten Ausführungsplan anzeigen'. (standardmäßig 3. Symbol nach 'Ausführen')

Dann werden die Abfragen untereinander detailiert verglichen und die Abfragekosten in Relation gesetzt. 🙂

Zu der Sache mit DataSet und Objekten:

Ist imo Geschmackssache, geht beides und schliesst sich auch gegenseitig nicht völlig aus. Sollte je nach Projektgröße, Situation, eigener Vorliebe eingesetzt bzw. kombiniert werden. 😉

Hallo Sharoo,

das habe ich gemacht und das Ergebniss war bei beiden das gleiche.
Die Daten auf Objekt mappen und dann die Objekte in einer List<objekt> verwalten, finde ich persönlich besser und es entsteht, glaube ich, auch nicht so ein Overhead wie beim DataSet.

Markus

Original von Reverent
das habe ich gemacht und das Ergebniss war bei beiden das gleiche.

Sprich Abfragekosten (in Relation zum Batch) genau 50%?

Weil nur das wäre ja hier erstmal interessant. Wenn's genau 50/50 ist, ist es wirklich egal, was du nimmst. Obwohl ich persönlich die Variante mit den JOINS bevorzugen würde. 8)

Original von Reverent
MS SQL Server 2005

Hallo ihr Freunde der leichten Unterhaltung 🙂

Ich habe da mal ne Frage die nur am Rande mit C# zu tun hat, bitte nicht übel nehmen!
Welche Abfrage ist schneller besser u.s.w.

1.
select ... from a left join b on a.id_B = b.id left join c on a.id_C = c.id
where
a.id = 1;

oder

2.
select ... from a, b, c
where
a.id_B = b.id and
a.id_C = c.id and
a.id = 1;

Danke schon mal
Markus

Die beiden Abfragen sind nicht identisch weil dein 2.Beispiel übertragen auf Joins Inner Joins verwenden müsste.

select ... from a inner join b on a.id_B = b.id inner join c on a.id_C = c.id
where
a.id = 1;

Lg XXX

Gute DBs erkennen, dass man eine Multi-Where-Klausel zu einer Join-Abfrage optimieren kann. Der Vorteile des Joins sind schlicht die geringeren Datenmengen, die dabei entstehen. Bei kleinen DBs wird man das aber nicht sehen. Da müssen schon ein paar MB in den Tabellen stehen. Sinnvollerweise sollten die Datenmengen so groß sein, dass die DB die Tables nicht mehr cachen kann.

Was ist System schonender,
die Tabellen in DataSet's zu speichern oder sich die Mühe machen die Tabellen auf eigene Objekte zu mappen?

Ich bin sicher, wenn man es geschickt anstellt kann man wie du so schön sagst "System schonender" arbeiten, wenn man selbst was programmiert. Das sollte dann aber schon gut durchdacht und an die Bedürfnisse des Programmes angepasst sein, sonst würd ich besser gleich DataSet nehmen.
Hab mich mal lange mit diesem Thema beschäftigt und auch eine Fachbereichsarbeit darüber geschrieben. 😉

Ach ja, wegen deinen SQL-Statements: Mir wurde in der Schule immer gesagt joins sind schneller, kann aber auch gut sein dass blackcoin recht hat und das in der Zwischenzeit schon egal ist.

Mfg Preli

Also ich kann mich an erinnern, dass (damals seufz) in der Datenbank-Vorlesung gesagt wurde, dass JOIN nur eine einfachere Schreibweise (eingeführt mit SQL-2) für die Verbindung von Tabellen ist. Intern wandelt es das DB-System wieder in WHERE-Bedingungen um.
Ob diese Aussage heute noch stimmt oder ob die neuen DB-Systeme dann doch verschiedene Algorithmen haben, weiß ich nicht. Ich wollte es nur mal in diese Diskussion einwerfen.

Grüße
Elric

Original von Reverent
Hallo Sharoo,

das habe ich gemacht und das Ergebniss war bei beiden das gleiche.
Die Daten auf Objekt mappen und dann die Objekte in einer List<objekt> verwalten, finde ich persönlich besser und es entsteht, glaube ich, auch nicht so ein Overhead wie beim DataSet.

Markus

Dieser "Overhead" hat aber auch einige Vorteile, wie zum Beispiel das Suchen, Filtern und Sortieren. Im DataSet sind diese "Features" bereits implementiert, und können mit sehr wenig Codezeilen benutzt werden. Das sind features die Endbenutzer sehr gerne sehen und die usability enorm steigern.

Ich mag den Zugriff auf die Daten mit dem ewigen casten beim Dataset auch nicht wirklich, darum arbeite ich an einer eigenen BindingList<>. SortableeBindinglist habe ich hingekrigt, aber leider ohne advanced sorting. Eine SortSearchableBindingList<> bin ich noch dran, werde meine Ergebnisse auch hier posten. Das Ziel ist es, eine generische BindingList, welche alle grundfunktionen, wie Suchen, Filtern, Sortieren, Laden, Speichern etc. ohne diesen "Overhead" ermöglicht.

Gruss,
.unreal

Aus einem

Select a,b,c from X, Y, Z

wird intern ein

Select a,b,c from X JOIN Y JOIN Z

Das heisst, dass in diesem Fall ein Kreuzprodukt aus drei Dimensionen erzeugt wird. Hat jede Tabelle 10 Zeilen werden 1000 Zwischenzeilen, die dann per where gefiltern werden.

Im Falle der Verwendung von Join werden zunächst 100 Zwischenzeilen erzeugt, die durch den Where-Filter - sagen wir auf 20 - reduziert werden.

Durch den 2. Join wird ein weiteres Kreuzprodukt aus der letzten Tabelle (10) mit der Zwischentabelle (20) erzeugt. Macht 200. Plus die 100 zuvor.

Statt also 1000 Zeilen zu erzeugen und zu filtern werden nur 300 erzeugt. Zudem sind die Filterbedingungen einfacher.

Daher muss man so eng wie möglich joinen und filtern.