Die letzte Zeile aus der DB schnell auslesen?

[AlexII]

Hallo,

kann man die letzte Datenzeile aus der DB ohne einer Schleife auslesen?
Zur Zeit mache ich es so, würde aber die Abfrage etwas verkürzen, Falls machbar ist, da bei vielen Datensätzen kann man Code sehr langsam sein.

Delphi-Quellcode:

    // Die letzte Kundennummer des Teilnehmers auslesen
    SQLQueryLastKNr.Close;
    SQLQueryLastKNr.SQL.Text := 'SELECT knr FROM tbteilnehmer';
    SQLQueryLastKNr.Open;

    while not SQLQueryLastKNr.Eof do
    begin
      LastKNr := SQLQueryLastKNr.FieldByName('knr').AsInteger;
      SQLQueryLastKNr.Next;
    end;
    // Ende 

    SQLQuery1.ParamByName('knr').AsInteger := LastKNr + 1;

Danke!

[Bernhard Geyer]

Und was kennzeichnet eine letzte Datenzeile aus?
DBs sind mengenorientiert. Solange du nicht definierst was "letzte Datenzeile" ausmachst geht das nicht.
Deine Abfrage wird nur zufälligerweise das gewünschte Ergebnis liefern. Mein Goldkugel sagt mir das du eine Autoinc-ID mitführst und der größte Wert dem letzten eingefügten Datensatz entspricht den du haben willst.

Also ein

Code:

SELECT Max(knr) FROM tbteilnehmer group by knr

[AlexII]

AUTOINCREMENT ist bei mir nur die ID, die Kundennummer nicht, da SQLite AUTOINCREMENT nur ein Mal erlaubt. Ich muss also die Kundennummer selber hoch zählen, daher

Zitat:

SQLQuery1.ParamByName('knr').AsInteger := LastKNr + 1;

Wieso machst Du eigentlich "group by knr"?

[Bernhard Geyer]

Zitat:

Zitat von AlexII (Beitrag 1285584)

Wieso machst Du eigentlich "group by knr"?

I.d.R. muss man bei Aggregatfunktionen (http://www.w3schools.com/sql/sql_functions.asp) ein Group By machen wenn man sie anwenden will. Im Obigen fall ist das aber falsch aus dem Kopf geschrieben. Lass es einfach weg.

[mjustin]

Zitat:

Zitat von AlexII (Beitrag 1285580)

kann man die letzte Datenzeile aus der DB ohne einer Schleife auslesen?

Ja, wie beschrieben mit MAX(), wenn auf dem relevanten Feld (hier die Kundennummer) ein Index existiert.
Je nach Datenbank ist ein absteigend sortierter Index erforderlich wenn es möglichst schnell funktionieren soll.
(InterBase in den mir bekannten Versionen klappert bei MAX und nur aufsteigendem Index noch durch alle Sätze)

[himitsu]

Laut Beschreibung/Überschrift woller er ja nicht die größte Nummer, sondern die Letzte, also

SQL-Code:

SELECT knr FROM tbteilnehmer ORDER BY xxx DESC LIMIT 1

:stupid:
xxx = akn
oder nach was auch immer die Daten sortiert sein sollen (z.B. insert_date oder so)


Ansonsten wäre sein Code auch irgendwie falsch.

Delphi-Quellcode:

LastKNr := -1;  // warum hast du die Variable nicht initialisiert? Was soll denn rauskommen, wenn es keine Datensätze gibt!
while not SQLQueryLastKNr.Eof do
begin
  if LastKNr < SQLQueryLastKNr.FieldByName('knr').AsInteger then
    LastKNr := SQLQueryLastKNr.FieldByName('knr').AsInteger;
  SQLQueryLastKNr.Next;
end;

[AlexII]

Habe diese Selektion gefunden, die gut funktioniert. :thumb:

Delphi-Quellcode:

SELECT knr FROM tbteilnehmer WHERE id_teilnehmer=(SELECT MAX(id_teilnehmer) FROM tbteilnehmer)

Die id_teilnehmer hat wohl den Index, die knr nicht wie es scheint.

[himitsu]

SQL-Code:

SELECT knr FROM tbteilnehmer ORDER BY id_teilnehmer DESC LIMIT 1

:stupid: (Beschreibung siehe Nachtrag meine letzter Antwort)

[p80286]

Zitat:

Zitat von himitsu (Beitrag 1285587)

Laut Beschreibung/Überschrift woller er ja nicht die größte Nummer, sondern die Letzte, also

SQL-Code:

SELECT knr FROM tbteilnehmer ORDER BY xxx DESC LIMIT 1

:stupid:
xxx = akn
oder nach was auch immer die Daten sortiert sein sollen (z.B. insert_date oder so)

Zitat:

// Die letzte Kundennummer des Teilnehmers auslesen

Da wahrscheinlich mehrere Teilnehmer vorhanden sind, ist

SQL-Code:

select max(knr) from tbteilnehmer Group by teilnehmer-id

gar nicht so falsch.

Gruß
K-H

[AlexII]

Zitat:

Zitat von himitsu (Beitrag 1285589)

SQL-Code:

SELECT knr FROM tbteilnehmer ORDER BY id_teilnehmer DESC LIMIT 1

:stupid: (Beschreibung siehe Nachtrag meine letzter Antwort)

Was heißt "DESC LIMIT 1"?

[DeddyH]

Absteigend sortieren und nur den 1. Datensatz zurückgeben.

[AlexII]

Zitat:

Zitat von p80286 (Beitrag 1285590)

SQL-Code:

select max(knr) from tbteilnehmer Group by teilnehmer-id

gar nicht so falsch.

Da macht SQLite irgendwie nicht mit... wahrscheinlich weil knr keinen Index hat.

[Bernhard Geyer]

Limit: http://www.mysqltutorial.org/mysql-limit.aspx
Desc: http://www.w3schools.com/sql/sql_orderby.asp

[AlexII]

Zitat:

Zitat von DeddyH (Beitrag 1285592)

Absteigend sortieren und nur den 1. Datensatz zurückgeben.

Ich Suche aber nach dem letzten Datensatz.

[p80286]

Wenn absteigend sortiert ist, ist der erste der größte!

Gruß
K-H

P.S.
nochmal den "letzten" gibt es in einer Datenbank nicht!

[AlexII]

Zitat:

Zitat von p80286 (Beitrag 1285597)

Wenn absteigend sortiert ist, ist der erste der größte!

Gruß
K-H

P.S.
nochmal den "letzten" gibt es in einer Datenbank nicht!

Stimmt!

[mjustin]

Zitat:

Zitat von AlexII (Beitrag 1285580)

kann man die letzte Datenzeile aus der DB ohne einer Schleife auslesen?

Ganz alternative Lösung: in einer eigenen Tabelle immer die letzte Datenzeile speichern, sobald ein neuer Datensatz angelegt wird. Ganz ohne eine Definition, was "letzte" bedeutet, bleibt es Stochern im Nebel :)

[AlexII]

Zitat:

Zitat von mjustin (Beitrag 1285599)

Zitat:

Zitat von AlexII (Beitrag 1285580)

kann man die letzte Datenzeile aus der DB ohne einer Schleife auslesen?

Ganz alternative Lösung: in einer eigenen Tabelle immer die letzte Datenzeile speichern, sobald ein neuer Datensatz angelegt wird. Ganz ohne eine Definition, was "letzte" bedeutet, bleibt es Stochern im Nebel :)

Muss ich wohl machen, da sonst wenn der letzte Kunde gelöscht wird, bekommt der neue seine KNr.

[mjustin]

Zitat:

Zitat von AlexII (Beitrag 1285605)

Muss ich wohl machen, da sonst wenn der letzte Kunde gelöscht wird, bekommt der neue seine KNr.

:cheers:

[DeddyH]

Wenn es zu dem Kunden bereits abhängige Daten gibt, wird das mit dem Löschen eh schwierig (bei entsprechender Datenstruktur).

[Dejan Vu]

Obwohl die Idee mit dem 'ORDER BY DESC LIMIT' meistens echt brauchbar ist, würde ich mir bei großen Datenmengen 2x überlegen, ob ich diesen Weg gehen soll. Denn wider dem gesunden Menschenverstand (ist das grammatikalisch überhaupt korrekt :gruebel:?) scheinen einige RDBMS bei der Sortierung etwaige Indexe zu ignorieren (sofern es sich nicht um den Primär/Clustered Index handelt) und rödeln ewig und drei Tage rum, bis sie das letzte Element ausspucken. Andere verwenden einen Index, aber auch nur dann, wenn er auch absteigend sortiert ist.

Ein Aggregat, wie 'SELECT MAX(ID)' ist dagegen -mit Index- schnell genug.

Im Zweifelsfall würde ich die Kandidaten durchprobieren.

Bei kleinen Datenmengen ist das aber wurscht.

Zitat:

Zitat von DeddyH (Beitrag 1285610)

Wenn es zu dem Kunden bereits abhängige Daten gibt, wird das mit dem Löschen eh schwierig (bei entsprechender Datenstruktur).

Aber auch nur dann, wenn man Foreign Keys benutzt, also Schattenparker ist. :stupid:

[himitsu]

Um das einfach nochmal genauer aufzuzeigen

SQL-Code:

SELECT knr 
FROM tbteilnehmer 
ORDER BY id_teilnehmer DESC 
LIMIT 1

bzw.

SQL-Code:

SELECT
  knr 
FROM
  tbteilnehmer 
ORDER BY
  id_teilnehmer DESC 
LIMIT
  1

Da wird dann verständlicher was zusammengehört.

• nimm alle Daten aus der Tabelle (da kein WHERE)
• sortiere Dieses umgekehrt (DESC)
• nimm nur das Letzte Erste (LIMIT 1) ...

Das Erste (SORT id_teilnehmer DESC) ist ja der Letzte (SORT id_teilnehmer ASC), vor der Umsortierung.

[DeddyH]

Zitat:

Zitat von Dejan Vu (Beitrag 1285612)

Zitat:

Zitat von DeddyH (Beitrag 1285610)

Wenn es zu dem Kunden bereits abhängige Daten gibt, wird das mit dem Löschen eh schwierig (bei entsprechender Datenstruktur).

Aber auch nur dann, wenn man Foreign Keys benutzt, also Schattenparker ist. :stupid:

Jo, wer braucht schon referentielle Integrität? Das ist eh nur wieder so ein modisches Zeugs :stupid:

[Bernhard Geyer]

Zitat:

Zitat von DeddyH (Beitrag 1285617)

Zitat:

Zitat von Dejan Vu (Beitrag 1285612)

Zitat:

Zitat von DeddyH (Beitrag 1285610)

Wenn es zu dem Kunden bereits abhängige Daten gibt, wird das mit dem Löschen eh schwierig (bei entsprechender Datenstruktur).

Aber auch nur dann, wenn man Foreign Keys benutzt, also Schattenparker ist. :stupid:

Jo, wer braucht schon referentielle Integrität? Das ist eh nur wieder so ein modisches Zeugs :stupid:

Daten löschen? In diesem Bereich wäre es vom Datenmodell wohl sinnvoller eine Flag "inaktiv" zu vergeben statt alle Daten zu löschen.

[DeddyH]

Gelöschte Kunden kann aber kein Buchprüfer mehr kontrollieren :mrgreen:. Langsam wird es aber OT, oder?

[Bernhard Geyer]

Zitat:

Zitat von DeddyH (Beitrag 1285622)

Gelöschte Kunden kann aber kein Buchprüfer mehr kontrollieren :mrgreen:. Langsam wird es aber OT, oder?

Ich habe nicht damit angefangen :roll:

Aber ich denke es ist alles relevante gesagt.
Oder gibt’s noch Fragen Hauser - äh - AlexII?

[AlexII]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1285624)

Oder gibt’s noch Fragen Hauser - äh - AlexII?

Bin jetzt bei dieser Lösung geblieben:

Delphi-Quellcode:

SELECT knr FROM tbteilnehmer WHERE id_teilnehmer=(SELECT MAX(id_teilnehmer) FROM tbteilnehmer)

Aber wie vermeide ich, dass ein neuer Kunde die letzte gelöschte KNr bekommt?

[DeddyH]

Willst Du wirklich Kunden löschen können? Lies doch #24 noch einmal durch, das erscheint mir persönlich die vernünftigere Lösung zu sein.

[Bernhard Geyer]

Oder andersweitig die schon vergebenen Nummern merken.
Auch wenns hier nicht mehr geht. Für solche Unique-IDs verwenden wir bei uns GUIDs. Immer eindeutig und wenn es eh nur einer DB-System interne Nummer darstellt stört es nicht das sie nicht sprechend lesbar sind

[mjustin]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1285618)

Daten löschen? In diesem Bereich wäre es vom Datenmodell wohl sinnvoller eine Flag "inaktiv" zu vergeben statt alle Daten zu löschen.

In diesem Bereich muss man eventuell auch das BDSG beachten und gegebenenfalls doch löschen.

[EgonHugeist]

@AlexII

keine Ahnung, ob dich schon mal einer darauf verwiesen hat, dass du das mit SQLite gar nicht brauchst.
Schau mal hier: https://www.sqlite.org/autoinc.html rein..

[Bernhard Geyer]

Zitat:

Zitat von EgonHugeist (Beitrag 1285642)

@AlexII

keine Ahnung, ob dich schon mal einer darauf verwiesen hat, dass du das mit SQLite gar nicht brauchst.
Schau mal hier: https://www.sqlite.org/autoinc.html rein..

Siehe Beitrag #3

[EgonHugeist]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1285644)

Zitat:

Zitat von EgonHugeist (Beitrag 1285642)

@AlexII

keine Ahnung, ob dich schon mal einer darauf verwiesen hat, dass du das mit SQLite gar nicht brauchst.
Schau mal hier: https://www.sqlite.org/autoinc.html rein..

Siehe Beitrag #3

Right! War hier nicht ganz auf dem Laufenden :oops:

[mkinzler]

Zitat:

Zitat von mjustin (Beitrag 1285638)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1285618)

Daten löschen? In diesem Bereich wäre es vom Datenmodell wohl sinnvoller eine Flag "inaktiv" zu vergeben statt alle Daten zu löschen.

In diesem Bereich muss man eventuell auch das BDSG beachten und gegebenenfalls doch löschen.

Dann aber nicht den kompletten Kundendatensatz sondern ggf. nur betroffene personenbezogene Daten.

[Jasocul]

Na dann hoffe ich mal, dass die Anwendung nie als Multi-User-Anwendung zum Einsatz kommt.
Bei der vorgesehenen Lösung dürfte es zu Problemen kommen, falls mindestens 2 Anwender zur selben Zeit einen neuen Datensatz erfassen.

Ein AutoInc-Feld funktioniert doch sehr gut. Man muss sich bei der Programmierung in solchen Fällen nur die Mühe machen, keine datenbanksensitiven Komponenten zu verwenden. Erst wenn der Anwender speichern will, wird der Datensatz eingetragen. Dann gibt es auch keine Lücken und doppelte Nutzung gelöschter Nummern ist damit auch verhindert.

[mkinzler]

SQLite hört sich eher nicht nach MultiUser an.

[Jasocul]

Zitat:

Zitat von mjustin (Beitrag 1285638)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1285618)

Daten löschen? In diesem Bereich wäre es vom Datenmodell wohl sinnvoller eine Flag "inaktiv" zu vergeben statt alle Daten zu löschen.

In diesem Bereich muss man eventuell auch das BDSG beachten und gegebenenfalls doch löschen.

Bitte dann aber das BDSG genau lesen. Es gibt gesetzlich festgelegte Aufbewahrungszeiten, die gegen eine Löschung sprechen. Ich vermute, dass das mit dem "eventuell" gemeint war, aber ich wollte das nochmal deutlich hervorheben, bevor unzulässiger weise gelöscht wird.

[Jasocul]

Zitat:

Zitat von mkinzler (Beitrag 1285677)

SQLite hört sich eher nicht nach MultiUser an.

Im Grunde sehe ich das auch so, aber oft werden Anwendungen auch mit "kleinen" DB-Systemen entwickelt und später portiert. Mal abgesehen davon blockiert SQLite die Datenbank für ein paar Millisekunden nur während der Schreibvorgänge. Also theoretisch kann man trotzdem in eine Falle laufen.

[p80286]

Zitat:

Zitat von Jasocul (Beitrag 1285680)

Zitat:

Zitat von mkinzler (Beitrag 1285677)

SQLite hört sich eher nicht nach MultiUser an.

Im Grunde sehe ich das auch so, aber oft werden Anwendungen auch mit "kleinen" DB-Systemen entwickelt und später portiert.

Wenn angeblich eine Kundennummer verwaltet wird, dann sollte man sich durchaus Gedanken für eine "große" Datenbank machen. Bei eine Verwaltung für CDs (gibt's die überhaupt noch?)könnte man das etwas schleifen lassen. Nur wenn man's im kleinen nicht übt, dann wundert man sich bei den "großen".

Gruß
K-H

[mkinzler]

Bei einem richtigen DBMS wird man dies dann auch ganz anders lösen.