Abfrage: Ist Datensatz bereits vorhanden?

[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).