Abfrage: Ist Datensatz bereits vorhanden?

[Dejan Vu]

Zitat:

Zitat von himitsu (Beitrag 1266076)

- das innere Select gibt schon deine 1 zurück und bei "0" halt Nichts
- aber vorallem "case when" ist doch sinnlos?

'EXISTS' gibt kein 1/0 zurück (per ANSI SQL). Den Datentyp BOOL gibt es in ANSI SQL so nicht, weswegen man das auch nicht -wie in einer Programmiersprache- mit Werten mischen kann. Bei SQLite geht das aber sehr wohl, nur wusste ich das wusste bisher nicht. :thumb:

Zitat:

SQL-Code:

SELECT true FROM table WHERE id = :id

gibt einen Datensatz oder keinen. Das löst die Aufgabe nicht, per SQL eine 0/1 (true/false) zu liefern.

[Perlsau]

Zitat:

Zitat von Dejan Vu (Beitrag 1266075)

Zitat:

Zitat von Perlsau (Beitrag 1266072)

Zitat:

Zitat von BenneX (Beitrag 1266070)

Über eine Eindeutigkeit, bspw.

Delphi-Quellcode:

SELECT * FROM Kunden WHERE Name=Mustermann

Ja und wo ist da das Problem? Du kannst doch die Datensätze, die du damit erhältst, zählen, oder etwa nicht?

Zählen ist keine gute Idee, weil dazu die gesamte Tabelle (oder zumindest der Index, wenn dieser angewendet wird) durchsucht werden muss.

Doch, ist es: Wenn er durch seine Where-Klausel die Datenmenge bereits stark eingeschränkt hat, muß er eben nicht die ganze Tabelle durchsuchen, um die Anzahl der zurückgelieferten Datensätze zu zählen: If Query.RecordCount > 0 Then ...

Ob Sql-Light Count kennt, weiß ich nicht. Jedoch überprüfe ich meine Tabellen so:

Code:

select count(NAME) from KUNDEN where NAME = 'Mustermann';

Das liefert mir direkt die Anzahl der Records, in denen der Name "Mustermann" lautet.

[DeddyH]

Wie soll denn der Datenbankserver die Anzahl der Datensätze ermitteln, ohne die Tabelle bzw. den Index komplett zu durchlaufen?

[Perlsau]

Bei Verwendung des SQL-Befehls Count muß er das gewiß. Zählt man jedoch die Anzahl der zurückgelieferten Datensätze (MyQuery.RecordCount) muß er das nicht, falls das betreffende Feld (Name) indiziert ist. Die zurückgelieferte Datenmenge, die nun gezählt wird, ist zudem bereits reduziert – falls nicht alle Kunden "Mustermann" heißen.

[BUG]

Zitat:

Zitat von Dejan Vu (Beitrag 1266083)

Das löst die Aufgabe nicht, per SQL eine 0/1 (true/false) zu liefern.

Sowas kann man sich prinzipiell mit UNION, SORT und LIMIT zusammenbasteln.

Ich würde bei größeren DBMS dann doch lieber eine Stored Procedure schreiben.

[jobo]

Was bedeutet wohl mehr Last für den "Server"?
Lokal eine Datensatzanzahl zu bestimmen oder eine Datensatzmenge an den Client zu schicken, der diese dann "zählt"?

Wir können sicher festhalten, dass die Frage nach Anzahl oder bloßer Existenz von Datensätzen, die bestimmten Kriterien entsprechen, die unaufwändigste ist. Der Aufwand "beschränkt" sich hier auf die vollständige "Findung" relevanter Datensätze oder im 2. Fall auf die "Findung" eines einzigen Datensatzes.

Die zugehörigen Daten dann an den Client zu übertragen, der sie als Query angefragt hat, ist in jedem Fall ein Zusatzaufwand, der die Sache nicht schneller oder schonender macht.
Wie sich das unter SQlite verhält, wo "Server" und "Client" identisch sind, sei mal dahin gestellt.

Eine Stored Procedure ist bei dem Verfahren und anderen kein Allheilmittel, sie hilft nur, Datenübertragung zwischen Server und Client zu sparen. Konkret macht das bei einem "Select count(*)" oder einer SP, die das gleiche abruft und als Parameter zurückgibt keinen Unterschied.

[Dejan Vu]

Zitat:

Zitat von Perlsau (Beitrag 1266089)

Doch, ist es: Wenn er durch seine Where-Klausel die Datenmenge bereits stark eingeschränkt hat, muß er eben nicht die ganze Tabelle durchsuchen, um die Anzahl der zurückgelieferten Datensätze zu zählen:

Überlege einfach nochmal: Natürlich muss 'er' das, denn um zu wissen, ob Name='Mustermann' ist, muss er die ganze Tabelle durchscannen (oder eben über einen Index-Seek). Und nach dem ersten Treffer könnte es ja noch einen zweiten geben. Beim Index ist das nicht ganz so tragisch, aber im Extremfall sind es 1 Quatrillion 'Mustermann'-Einträge. Und da kann man sich dann schon vorstellen, das das etwas länger dauert, ne wahr?

Also nochmal: Wir müssen natürlich den Worst-Case betrachten und der lautet: Auf der Spalte ist kein Index und 'Mustermann' ist der letzte Record. Daraus folgt: Table-Scan bis zum bitteren Ende. Oder es ist überhaupt kein 'Mustermann' vorhanden, und auch daraus folgt: Table-Scan bis zum letzten Datensatz.

Nehmen wir an, wir hätten einen Index. Dann muss bei einem Treffer trotzdem weitergezählt werden, was überflüssig ist, denn wir wollen ja nur wissen, ob es einen Eintrag gibt, und nicht wie viele.

In *jedem* Fall ist 'EXISTS' schneller oder gleich schnell wie 'COUNT'. Gleich schnell ist es nur in dem Fall, wo kein Treffer vorliegt.

Wenn Du die Anzahl wissen willst, führt naturgemäß kein Weg an einem COUNT vorbei, das ist ja irgendwie logisch. Hier wird doch aber nur verlangt, ob es einen entsprechenden Datensatz überhaupt gibt.

Zitat:

Zitat von jobo (Beitrag 1266099)

Eine Stored Procedure ist bei dem Verfahren und anderen kein Allheilmittel,

Na ja doch: Ob nun ein 'REPLACE OR INSERT' aufgerufen wird oder ein Einzeiler ist performancetechnisch ein und dieselbe Soße (über Nanosekunden wollen wir uns nicht streiten)

Code:

if EXISTS (select * from Tabelle where ID=:ID)
  update Tabelle..
else
  insert into Tabelle

Ich kann auch das ganze IF-Statement zum Server schicken (wenn der das denn kann). In jedem Fall (SQLite oder nicht) ist es immer besser, die Daten-hin-und-her-schickerei zwischen Server und Client zu minimieren und vor allen Dingen kein COUNT anstelle von EXISTS zu verwenden.

[BUG]

Zitat:

Zitat von jobo (Beitrag 1266099)

Eine Stored Procedure ist bei dem Verfahren und anderen kein Allheilmittel, sie hilft nur, Datenübertragung zwischen Server und Client zu sparen. Konkret macht das bei einem "Select count(*)" oder einer SP, die das gleiche abruft und als Parameter zurückgibt keinen Unterschied.

Das ist mir klar, aber es versteckt die hässlichen technischen Details, wie genau der boolesche Wert erzeugt wird.

[Bernhard Geyer]

Zitat:

Zitat von Perlsau (Beitrag 1266092)

Bei Verwendung des SQL-Befehls Count muß er das gewiß. Zählt man jedoch die Anzahl der zurückgelieferten Datensätze (MyQuery.RecordCount) muß er das nicht, falls das betreffende Feld (Name) indiziert ist. Die zurückgelieferte Datenmenge, die nun gezählt wird, ist zudem bereits reduziert – falls nicht alle Kunden "Mustermann" heißen.

Wenn ein DBMS sowas machen würde, würde ich es wegschmeißen.

Auch bei einem Count(*) verwendet der Server genauso die Indize wie beim Stupiden "Select * from" mit Zählen beim Client.
Zusätzlich muss er auch noch die eigentlichen Datensätze aus der Tabelle auslesen, die Daten für den Transport über Netzwerk und Co. aufbauen und abschicken.
Beim Count(*) braucht er wenn er den Passenden Index hat überhaupt nicht in die eigentliche Tabelle schauen bzw. diese Auslesen.

[vagtler]

Zitat:

Zitat von Perlsau (Beitrag 1266092)

Bei Verwendung des SQL-Befehls Count muß er das gewiß. [...]

Natürlich nicht.

http://de.wikipedia.org/wiki/Auswertungsplan