Abfrage: Ist Datensatz bereits vorhanden?

[BenneX]

Hallo da draußen,

für mein Programm muss ich in meiner Datenbank feststellen ob ein Datensatz bereits vorhanden ist oder noch nicht. Wie stelle ich dies nun am Besten an? Ausgabe als Boolean wäre wünschenswert.

Viele Grüße,
BenneX

[borncrush]

Ohne Programmierung erst einmal.

Wie lässt sich der Datensatz identifizieren?

Danach gehts weiter ... ;-)

[BenneX]

Über eine Eindeutigkeit, bspw.

Delphi-Quellcode:

SELECT * FROM Kunden WHERE Name=Mustermann

Mustermann hab ich gegeben, jetzt möchte ich herausfinden ob ich den Datensatz UPDATEN muss oder neu erstellen muss - und genau dies ist mein Problem :-/

[borncrush]

Na wenn es einen Datensatz mit diesem Namen gibt (Mustermann), dann musst also einen Eintrag erstellen, andernfalls updaten.

Also du stellst diese SQL-Select-Abfrage und erhälst ja ein Ergebnis. Erst einmal egal, mit welchem Inhalt.

Nun gut, überlege weiter. Zwei Zustände gibt es also. Datensatz da oder nicht. Wie könnte der sich z.B. bei der SELECT-Abfrage im Ergebnis unterscheiden? Und könntest Du etwas damit anfangen?

[Perlsau]

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?

[Medium]

Manche SQL Dialekte unterstützen direkt eine "UPDATE OR INSERT"-Funktion. Wie diese genau aussieht, hängt von deinem DMBS ab.

Edit: Für SQLite scheint es dafür RELPACE INTO zu geben. Damit lagert man den Schritt der Prüfung, ob ein Satz für eine ID schon existiert gemütlich in die DB aus, wo diese imho auch hin gehört. Drüber hinaus spart es ein paar Zeilen und etwas Traffic.

[Dejan Vu]

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.

Die effektivste Möglichkeit um herauszubekommen, ob ein Datensatz existiert, wäre imho ein ANY oder EXISTS:

SQL-Code:

 
select 
  case when exists (
    select 1 from Tabelle where Name='Mustermann'
    ) 
    then 1 
    else 0 
  end;

Das konkrete Problem (insert or update) ist natürlich bereits von Medium beantwortet.

[himitsu]

Warum so umständlich?
- SubSelect?
- das innere Select gibt schon deine 1 zurück und bei "0" halt Nichts
- aber vorallem "case when" ist doch sinnlos?
- - Auf die Frage gibt es als Antwort Ja oder Nein ... wozu also diese Antwort nochmal in 0 oder 1 umwandeln?
- -

SQL-Code:

select exists(select 1 from Tabelle where Name='Mustermann'); -- 1, true, *, irgendwas ... egal

PS:

Zitat:

Zitat von BenneX

Ausgabe als Boolean wäre wünschenswert.

SQL-Code:

SELECT true FROM table WHERE id = :id

Entweder gibt es einen Datensatz mit True oder es gibt keinen Datensatz.
Da es eh immer nur True geben kann, braucht man also nur die Anzahl der Datensätze prüfen (RecordCount/Empty/EOF) und der Inhalt ist praktisch egal.

[jobo]

Eigentlich ist schon alles gesagt, ich möchte nur anmerken, dass "Mustermann", also ein Name, idR nicht taugt, um eine Eindeutigkeitzu bestimmen.
Technisch gibt es dafür Primärschlüssel, logisch gibt es dafür Kundennummern bspw oder Kombinationen aus verschiedenen Feldern wie Name, Geburtsdatum, Adresse. Die werden dann von einem Menschen abgerufen und verglichen und der entscheidet sich dann für einen der Datensätze und dieser eine Datensatz kann über den technischen Primärschlüssel haargenau identifiziert und upgedated werden.

Wenn Du in die Verlegenheit kommen solltest, anhand eines mehrdeutigen Kriteriums den zu ändernden Datensatz bestimmen zu müssen, ist irgendwas schiefgelaufen. Ob
CSV mit Datenaktualisierung
Anforderung aus der Sachbearbeitung
oder was auch immer
Es werden immer eindeutige Kriterien benötigt.

[p80286]

"Eindeutigkeit" ist hier das wichtige Stichwort. In einer Adressdatenbank wird ein Klaus Müller oder Manfred Fischer problemlos mehrmals auftauchen. Handelt es sich hierbei um Personen mit mehr als einer Adresse oder handelt es sich um zwei unterschiedliche Personen? Und dann ist ja auch die Frage was in der DB fehlt. Liegen beispielsweise Städte und Postleitzahlen in einer Tabelle oder in zwei getrennten Tabellen?

Gruß
K-H

[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

[Dejan Vu]

Zitat:

Zitat von DeddyH (Beitrag 1266090)

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

Zitat:

Zitat von Perlsau (Beitrag 1266092)

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

Zitat:

Zitat von vagtler (Beitrag 1266113)

Natürlich nicht.

Nehmen wir ein stinknormales RDBMS. Tabellen und B-Tree Index (ist am gebräuchlichsten).
Dann haben wir 3 Fälle, wie ein 'COUNT(*) WHERE field = :foo' ermittelt wird.

1. Index auf 'field' vorhanden. Die Einträge sind sortiert vorhanden im Index. Das RDBMS findet den 1.Eintrag der WHERE - Bedingung. Da es sich um eine Äquivalenz ('=') handelt, zählt man einfach die Einträge 'rechts' vom gefundenen Eintrag, die gleich sind ('Index-Seek').
2. Anderer Index vorhanden, der 'field' enthält. Das RDBMS liest den Index ein, was wesentlich schneller geht und rennt sequentiell durch, um alle Records mit der Bedingung zu finden. ('Index Scan').
3. Kein Index vorhanden. Das RDBMS muss die gesamte Tabelle durchlaufen ('Table Scan').

In jedem der drei Fälle gibt es noch Optimierungsmöglichkeiten, je nach Feld- und Indegröße sowie WHERE-Bedingung. Ist die Tabelle sehr klein, kann ein Table-Scan schneller sein, als eine Index-Suche, das entscheidet der Optimizer. mySQL kennt andere Indexstrukturen, die sich sicherlich für den einen oder anderen Fall besser eignen, aber im Groben wird selbst SQLite das so handhaben, wie beschrieben. Das ist ja banale Algorithmik.

[BenneX]

Hallo Leute! Danke für die vielen Antworten INSERT OR REPLACE war genau was ich gesucht habe!

Könnt Ihr mir noch verraten wie ich nun die Ergebnisse einer SELECT abfrage als GRID auf meinem Formular anzeigen lassen kann? Finde dazu leider keine weiteren Informationen ...

Grüße,
BenneX!

[Sir Rufo]

Ist eigenlich ganz simpel:

Code:

DataSet -> DataSource -> DBGrid

TDataSource.DataSet und TDbGrid.DataSource
Das DataSet ist natürlich deine Query-Komponente mit der Abfrage

[jobo]

Zitat:

Zitat von Dejan Vu (Beitrag 1266106)

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)

Bitte? Was nun? Kein Allheilmittel oder doch und dann je nachdem das gleiche Argument?
Schneller gedacht, als getippt? ;)

Ich schreibs nochmal:
Eine SP ist per se nicht schneller als ein einzelnes SQL Statement, besonders dann, wenn die SP nur wirklich das SQL Statment kapselt.
Daher spare <Ich> mir gern den Impact, ein SP statisch zu erstellen, wenn ich das gleich mit einem Select erreiche.
Warum ist eine SP häufig schneller? Weil sie Traffic zwischen Client und Server spart oder auch Techniken einsetzen kann, die mit reinem SQL nicht funktionieren.
Natürlich gibt es noch ein halbes dutzend andere Gründe, SP zu nutzen..

[p80286]

Zitat:

Zitat von jobo (Beitrag 1266153)

..oder auch Techniken einsetzen kann, die mit reinem SQL nicht funktionieren.

Jetzt werden sie wieder wach, die Erbsenzähler. :duck:

Gruß
K-H

[Dejan Vu]

Ach so, klar. Da habe ich dich missverstanden.

Ich verwende SP, um Datenbanklogik zu kapseln. z.B. hat nicht jedes RDBMS den REPLACE/INSERT Befehl. In einem anderen Fall haben wir den Zugriff auf eine Legacy-DB mit SP und Views abstrahiert, dann die neue Applikation gebaut und anschließend sukkezzive die DB ausgetauscht. Dank Abstraktionslayer (SP/View) kein Problem.

Aber das ist ein gaaanz anderes Thema und diesmal keine Erbsenzählerei.

[jobo]

OT
@K-H: Meinst Du mich? Ein Fedehandschuh? :)

Ich fand lediglich die "Formulierung" von dejan vu etwas wirr. Und da immer gern mal propagiert wird, dass eine SP eben schneller ist (egal ob es passt oder nicht) und also am besten usw., musste ich da mal nachhaken.

Genaugenommen ist es hier im Thread nicht mal Erbsenzählerei, sondern eher Bohnen (server) oder so, wo es um Erbsen (sqlite) geht.

Also, wer Äpfel mit Birnen vergleicht oder Bohnen mit Erbsen, macht wahrscheinlich einen riesen Fehler.
Interessiert die meisten nicht die Bohne, also danke für Deine Aufmerksamkeit!
/OT

[p80286]

@Jobo
Ich meinte das reine SQL.

Die meisten Behauptungen, die hier aufgestellt wurden, kann ich leider nicht mehr nachvollziehen. Ein count(*) ist nach meiner Erfahrung immer noch der schnellste Weg zu sehen ob etwas da ist oder nicht.

In den Anfangszeiten des MS-SQL-Servers waren diese Diskussionen allerdings noch notwendig, ich hatte angenommen, daß die Zeiten der Abfragen mit Optimierungshinweisen, der täglichen Indexpflege und der richtigen Join-Reihenfolge in der Zwischenzeit vorbei sind. So kann man sich täuschen.

Gruß
K-H

[BenneX]

Zitat:

Zitat von Sir Rufo (Beitrag 1266139)

Ist eigenlich ganz simpel:

Code:

DataSet -> DataSource -> DBGrid

TDataSource.DataSet und TDbGrid.DataSource
Das DataSet ist natürlich deine Query-Komponente mit der Abfrage

Hallo Sir Rufo,

Danke für Deine Antwort.

Ich habe folgendes ausprobiert:
DBGrid1 auf meine Form gezogen
und mittels

markieren Delphi-Quellcode:
table := Datenbank.GetTable('SELECT * FROM OGame');
DBGrid1.DataSource := table;
table ist hierbei TSQLiteTable.

Leider kriege ich nur den Fehler: Inkompatible Typen TDataSource und TSQLiteTable.

Wo liegt mein Fehler?

Grüße!

[DeddyH]

Das DBGrid mit einer TDatasource (das ist eine Komponente) verbinden und die Datasource mit einem TDataset (Deiner Tabelle).

[BenneX]

Also unter DBGrid1 stelle ich als DataSource DataSource1 ein, unter DataSource1 stelle ich SQLDataSet1 als DataSet ein und was mache in nun mit SQLDataSet1?

[mkinzler]

Als DataSet kannst du auch Deine Table verwenden (wenn diese ein DataSet ist)

[BenneX]

Dann bekomme ich nur die Meldung "Ungültiger Eigenschaftswert".
mein Table ist ein TSQLiteTable.

[p80286]

Wenn Du eine ADOQuery verwendest kann das z.B. so aussehen:

Delphi-Quellcode:

object Form1: TForm1
  Left = 192
  Top = 124
  Width = 870
  Height = 640
  Caption = 'Form1'
  Color = clBtnFace
  Font.Charset = DEFAULT_CHARSET
  Font.Color = clWindowText
  Font.Height = -11
  Font.Name = 'MS Sans Serif'
  Font.Style = []
  OldCreateOrder = False
  PixelsPerInch = 96
  TextHeight = 13
  object DBGrid1: TDBGrid
    Left = 248
    Top = 112
    Width = 33
    Height = 25
    [B]DataSource = DataSource1[/B]
    TabOrder = 0
    TitleFont.Charset = DEFAULT_CHARSET
    TitleFont.Color = clWindowText
    TitleFont.Height = -11
    TitleFont.Name = 'MS Sans Serif'
    TitleFont.Style = []
  end
  object ADOQuery1: TADOQuery
    ConnectionString = 'Provider=MSDASQL.1'
    Parameters = <>
    Left = 96
    Top = 112
  end
  object DataSource1: TDataSource
    [B]DataSet = ADOQuery1
[/B]    Left = 176
    Top = 112
  end
end

Gruß
K-H

[BenneX]

Hallo, danke für die Antworten. Bin jetzt vom meinem Wrapper auf dbexpress umgestiegen ... gibt einfach mehr Einsteigerfreundliche Infos dazu.

Viele Grüße,
BenneX!