Die letzte Zeile aus der DB schnell auslesen?

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