Anzahl Datensätze einer Tabelle beschränken

[Hansa]

Zitat:

Zitat von DeddyH

Woher willst Du bei Deiner Methode denn wissen, dass Du den ältesten DS erwischst?

Über die ID bzw. den primary key. Wie denn sonst ?

Nächster Vorschlag :

Delphi-Quellcode:

procedure TForm1.btn1Click(Sender: TObject);
var Anz : Integer;
    MinID,
    MaxID : Integer;
begin
  DS1.Close;
  DS1.SelectSQL.Text := 'SELECT MIN (ID) AS IDMIN FROM TESTTABLE';
  DS1.Open;             // ^^ momentane Anzahl ermitteln
  MinID := DS1.FieldByName ('IDMIN').AsInteger;
  DS1.Close;
  DS1.SelectSQL.Text := 'SELECT MAX (ID) AS IDMAX FROM TESTTABLE';
  DS1.Open;
  MaxID := DS1.FieldByName ('IDMAX').AsInteger;
  if MaxID > 3 then begin
    DS1.Close;
    DS1.SelectSQL.Text := 'DELETE FROM TESTTABLE WHERE ID ='+IntToStr (MinID);
    DS1.Open;
    DS1.Close;
    DS1.SelectSQL.Text := 'SELECT * FROM TESTTABLE WHERE ID ='+IntToStr (MaxID);
    DS1.Open;
    DS1.Insert;
    DS1.FieldByName('CITYNO').AsInteger := MaxID + 1;
    DS1.Post;
    Transaction1.Commit;
    DB1.Close;
    Close;        // Form schliessen
  end;
end;

Wo bleibt denn eigentlich der Trigger ? :shock: :mrgreen:

Zitat:

Zitat von mkinzler

Zudem würde das auch unabhängig vom Programm funktionieren

Aber es betrifft immer noch die DB. Die stellt das Kernstück dar. Nicht das Programm ! Die EXE kann man wohl auch schnell mal im laufenden Betrieb austauschen. Aber die DB mal kurz umbauen ?

[DeddyH]

Zitat:

Zitat von hansa

Über die ID bzw. den primary key. Wie denn sonst ?

Dann musst Du aber auch nach dem sortieren, sonst wird das nix. Und wieso sollte man in der Planungsphase die DB nicht umbauen?

[Hansa]

Ein Order By mitzuschleppen ist in diesem Fall unnötig. Wenn das fehlt wird nach dem primary key sortiert. Sofern es eine fortlaufende interne ID gibt, dann geht das schon so. Wo steht übrigens was von Planungsphase ? :shock: Aber egal. Mein zweiter Vorschlag lässt sich wohl auch einfach in einem Trigger realisieren. Da es aber auch um Lösch-Operationen geht : man muss sich klar darüber sein, dass ein Trigger zuschlägt, ohne wenn und aber. Der kennt weder Freund noch Feind !

[exilant]

Zitat:

Zitat von Hansa

Wo bleibt denn eigentlich der Trigger ? :shock: :mrgreen:

Ist ein trivialer Zweizeiler.

before insert trigger:

=======

new.id = gen_id(mytableid,1);
if (new.id > 500000) then delete from mytable where id=new.id-500000;

=======

Das wars. Wo ist das Problem?

[shmia]

Wenn man bei jedem Einfügen gleich den ältesten Datensatz löscht (weil der Ringpuffer voll ist) verursacht das hohe
Kosten in Bezug auf Performance und Fragmentierung der DB.

Daher sollte man das Löschen der alten Daten besser gesammelt zu einem definierten Zeitpunkt (z.B. Programmende, einmal pro Woche,...) vornehmen.
Das hat folgende Vorteile:
* bessere Performance während des normalen Programmablaufs
* Fragmentierung bleibt geringer
* die Programmlogik ist klarer, weil das Löschen quasi an eine andere Stelle ausgelagert wurde
* flexibler - Anwender kann z.B. wählen zwischen "max. Anzahl der Records" oder "Alles älter als 6 Monate löschen".
* das Löschen alter Daten könnte auch nachts gesteuert über ein Script ablaufen.
* das Löschen kann auch mit einer Archivierung verbunden werden

[Muchacho]

Zitat:

Zitat von shmia

Wenn man bei jedem Einfügen gleich den ältesten Datensatz löscht (weil der Ringpuffer voll ist) verursacht das hohe
Kosten in Bezug auf Performance und Fragmentierung der DB.

Daher sollte man das Löschen der alten Daten besser gesammelt zu einem definierten Zeitpunkt (z.B. Programmende, einmal pro Woche,...) vornehmen.

Genau so!

Bemerkung:

Hi :-D

Man sollte immer, falls möglich, nach Lösungen suchen die Zukunftsorientiert sind
und überall nach gleichem Prinzip anwendbar.

Ich kann an einem Tag auch 500000 Datensätze erzeugen.

Dann es ist wirklich schwer von einem ältesten Datensatz zu sprächen.
Wird einen Datensatz mit einer vermeidlich „älteren“ ID bearbeitet (z.B.: gestern)
und anschließend gespeichert ist er, wie ich meine, nicht mehr so alt wie vermutet.

So oder so eine ID darf in keinem Fall ein Maßstab für solche Handlungen sein,
da eben solche Probleme werden normalerweise via DATUM,
die in einem solchen Datensatz enthalten sein sollte, gelöst.

Und auch, wenn Datensätze nie bearbeitet werden sollen, sich auf eine ID zu verlassen,
ist nicht empfehlenswert, da das oberste Gebot ist:

Ich behalte die Kontrolle, und ich entscheide was alt ist und was nicht.

Gruß

Muchacho

[Jens Hartmann]

So, jetzt erst nochmal guten Abend oder besser gute Nacht von mir,

habe es leider länger nicht geschaft mich mit dem Thema auseinander zu setzt, jedoch habe ich Zwischendurch immer mal Eure Kommenetare gelesen. Dafür erstemal besten Dank.

Einfach vieleicht nochmal kurz eine Erläuterung von mir zu diesem Thema, ich persönlich finde den Weg mit der ID und das Problem in der DB zu lösen ist für meine Anwendung schon ganz OK.

Ich will mit dem Beschränken der Datensätze eigendlich ein Lizenztechnischen Problem lösen. Meine Software ist in verschiedenen Varianten erhältlich.

Je nach Kundenbedarf und Funktionsinhalt kann der Kunde auch die Größe vom Ringspeicher wählen. Dies bedeutet zwar keine Kostenerhöung für den Kunden, sondern lediglich eine Möglichkeit die Datenmenge einzuschränken.

Man kann beim Projektieren der Alarmanlage, welche diese Ereignisse zur Vefügung stellt, die ungefähre Datenmenge vorab schon ermitteln.

Verbindet man jetzt das Interesse des Kunden an den Daten mit dem Datenaufkommen, kann man ohne großen Aufwand die Sinnvolle Größe des Ringspeichers festlegen und hat in der Zukunft keinerlei Probleme, das der Kunden unötige Datenbanken hat, die er gar nicht mehr sehen will.

Vieleicht hat das ja noch zur Erläuterung geholfen.

Ansonsten schon mal recht vielen dank für Eure Antworten.

MFG

Gruß Jens

[Jens Hartmann]

Hallo zusammen,

So, ich habe das Problem jetzt gelößt. Der Vorschlag von...

Zitat:

Zitat von exilant

new.id = gen_id(mytableid,1);

SQL-Code:

if (new.id > 500000) then delete from mytable where id=new.id-500000;

war genau der richtige mit der Funktion die ich suchte. Ob das jetzt gut, elegant oder schlecht gelößt ist, mag ich nicht beurteilen. Vieleicht hat ja jemand was dazu zu sagen. Den Vorteil den ich in dieser Variante sehe, ist ganz klar das mein Programm damit beim einfügen von Daten keine arbeit hat und nicht immer auf die aktuelle Anzahl prüfen muss. Das übernimmt ja meine Datenbank. Daher denke ich sollte sich das Positiv auf die Perfomence des Programms auswirken.

Hier mal der fertige Trigger.

SQL-Code:

AS
begin
    if (new.ID is null) then
    new.ID = gen_id(GEN_MB256PLUS_ID, 1);
    if (new.id > 630000) then delete from mb256plus where id=new.id-630000;
end

Danke mal wieder für die Hilfe.

Gruß Jens

[edit=mkinzler]Code-Tag durch Sql-Tag ersetzt Mfg, mkinzler[/edit]

[tsteinmaurer]

Hallo Jens,

aber ID wächst ja dann immer an, oder? Würde auch bedeuten, dass er dann immer das DELETE ausführt, allerdings wird er dann ab einer bestimmten ID nichts mehr löschen, weil es die "kleinen" IDs nicht mehr gibt.

Außer ich habe auf die Schnelle was übersehen. :-D

[Jens Hartmann]

Da hast du leider was übersehen.

ID ist eine PK und wird immer hoch gezählt soll heißen...

Code:

    if (new.id > 630000) then delete from mb256plus where id=new.id-630000;

wenn PK_ID größer 630000 dann lösche PK_ID NEU - 630000 also PK_ID 1 wenn PK_ID NEU 630301
wenn PK_ID größer 630000 dann lösche PK_ID NEU - 630000 also PK_ID 2 wenn PK_ID NEU 630302

usw...

funktioniert auch genau so.

PK_ID wird ja trotzallem immer weiter geführt.

Gruß Jens