TADOCommand - Delete Befehl von mehreren Benutzern zu gleichen Zeit

[Sir Rufo]

Du stresst den Server schon ein wenig.

Beim Löschen muss der Server über zwei ungünstige Felder "char" und "date"/"char"? (sind die überhaupt in einem Index?).

Für die Computer könnte man auch eine eigene Tabelle erstellen die dann eine Id "int" hat und mit dieser Id referenziert man dann in den anderen Tabellen. Das alleine ist dann schon mal erheblich schneller. Wenn du jetzt noch einen Index darauf legst, dann sollte das nur einen Wimpernschlag dauern.

Code:

Computer
- Id int
- Name varchar
- ...

Computer_ClientFailure
- ComputerId int
- ...

Deine Verarbeitungsreihenfolge ist ungünstig:

• Viele Datensätze eintragen
• Viele alte Datensätze löschen

Wenn die alten Datensätze gelöscht werden sollen, warum löschst du diese dann nicht zuerst? Dann brauchst du auch keine Rücksicht auf den Zeitstempel nehmen. Einfach alles raus, was zu diesem Computer gehört.

Ja, ich höre den Einwand schon. Dafür nimmt eine Transaktion.

Delphi-Quellcode:

// Transaktion starten
Connection.StartTransaction;
try
  // alte Datensätze löschen
  ...
  // neue Datensätze eintragen
  ...
  // Transaktion abschliessen
  Connection.CommitTrans;
except
  // Transaktion zurückspulen
  Connection.RollbackTrans;
  raise;
end;

Jetzt sind entweder die aktuellen Datensätze enthalten oder es bleiben die alten in der Datenbank. Ein gemischtes Doppel ist aber ausgeschlossen.

Ausserdem beschleunigen solche Transaktionsblöcke die Verarbeitung nochmals

[Piro]

Vielen Dank, vielen Dank für die Tipps.

Ich habe in der Computer Tabellen eine ID (Primary Key) und in den Zusatztabellen eine ID (Primary Key) und eine ComputerID, welche den Fremdschlüssel zur Computer Tabelle darstellt.
In der Client_Failure Tabelle gehe ich über den ComputerNamen, das es auch vorkommen kann, dass nur hier Einträge geschrieben werden zum Computer z.B. bei einem WMI Fehler.

Es fehlt nur der Index. Reicht der Primary Key nicht schon aus? Er ist doch auch in Index.

Ich werde definitiv, die Daten erst löschen und dann neu hinzufügen. Macht echt mehr Sinn. Danke Sir Rufo.

Kurz zur Information, um Missverständnisse zu vermeiden.
Meine Anwendung wird immer gestartet, wenn der Benutzer sich am Rechner anmeldet.
Dann werden die Daten des Rechners ermittelt und in die DB geschrieben.

Mein Datenmodel sieht wie folgt aus.
Es gibt eine Computer Tabelle, welche alle Hauptinformationen zu einem Rechner hält. Das Feld ID stellt den Primary Key dar.
Zusatzinformationen, wie installierte Software oder verbunden Drucker oder welche Netzlaufwerke verbunden sind, werden in separaten Tabellen gespeichert mit der ID der Computer Tabelle, um später die Referenz zu haben.
Sollte während der Ermittlung und der Datenübertragung ein Fehler auftreten, wird dieser in eine Fehlertabelle gespeichert. Hier wird aber nur der Computer Name als Referenz gespeichert.

Vielen Dank schon mal für die ganzen Idee. Ich hoffe, dass bringt was.
Sven

[Dejan Vu]

Zitat:

2. Danach baue ich in einer zentralen Funktion die SQL Verbindung auf und halte sie aktiv mit KeepAlive = True.

Wieso? Was bewirkt das? Ein reconnect? Wann? Etwa bei Punkt 5?

[Piro]

Dadurch brauche ich nur einmal die Verbindung aufbauen, dann mit TADODataSet die Daten in die DB (Insert/Update) und zum Schluss das Löschen mit dem TADOCommand.

[jobo]

Zitat von Piro:

Vielen Dank, vielen Dank für die Tipps.

Ich habe in der Computer Tabellen eine ID (Primary Key) und in den Zusatztabellen eine ID (Primary Key) und eine ComputerID, welche den Fremdschlüssel zur Computer Tabelle darstellt.
In der Client_Failure Tabelle gehe ich über den ComputerNamen, das es auch vorkommen kann, dass nur hier Einträge geschrieben werden zum Computer z.B. bei einem WMI Fehler.

Es fehlt nur der Index. Reicht der Primary Key nicht schon aus? Er ist doch auch in Index.

Begriffe:
Ein Primary Key ist ein Constraint, ebenso wie ein Foreign Key, also Primärschlüssel, Fremdschlüssel.
Indizes sind unabhängig davon, werden aber netter Weise von den Systemen mit erstellt, wenn ein Primärschlüssel angelegt wird. Beim Foreign Key ist das anders. Da musst Du selbst ran. FK und Index definieren. Das kann schon eine Menge bringen, je nachdem wie groß die Detailtabellen sind.

Btw: was bringt eigentlich dieses Verfahren?
Wieso löscht Du morgens nicht gleich alles? Was später noch nicht aktualisiert wurde, ist doch dann eh eine Leiche.

[p80286]

Zitat von jobo:

Btw: was bringt eigentlich dieses Verfahren?
Wieso löscht Du morgens nicht gleich alles? Was später noch nicht aktualisiert wurde, ist doch dann eh eine Leiche.

Nicht ganz, das ist der letzte bekannte Wissensstand. Aber wenn bei jedem Rechnerstart die Daten neu geschrieben werden, würde ich über einen Trigger löschen. Viel interessanter finde ich allerdings die Frage nach den Daten. Geht da jedes mal ein halber Roman über die Leitung oder werden vorhandene Daten wirklich genutzt? Was passiert wenn z.b. ein Rechner noch nicht im Bestand ist?

Gruß
K-H

[jobo]

Zitat von p80286:

Zitat von jobo:

Btw: was bringt eigentlich dieses Verfahren?
Wieso löscht Du morgens nicht gleich alles? Was später noch nicht aktualisiert wurde, ist doch dann eh eine Leiche.

Nicht ganz, das ist der letzte bekannte Wissensstand. Aber wenn bei jedem Rechnerstart die Daten neu geschrieben werden, würde ich über einen Trigger löschen. Viel interessanter finde ich allerdings die Frage nach den Daten. Geht da jedes mal ein halber Roman über die Leitung oder werden vorhandene Daten wirklich genutzt? Was passiert wenn z.b. ein Rechner noch nicht im Bestand ist?

Anhand der Beschreibung habe ich nicht den Eindruck, das hier mit Bestandsdaten gearbeitet wird. Es scheint sich eher um so eine Art Log zu handeln. Daher ja auch meine Frage, wie oft sich das überhaupt ändert. Bei 2000 Usern gibt wahrscheinlich nur eine 2stellige Zahl von Druckern, pro User/Rechner sind dann vielleicht 1-3 eingerichtet, meinetwegen auch 10. Könnte man alles abbilden.

Wenn die Detaildaten umfangreich sind, könnte man die Analysedaten auch lokal ablegen und die tägliche Neuabfrage mit den Daten vom Vortag vergleichen. Erst bei Differenzen den Server überhaupt kontaktieren und updaten.
Falls ständig massiv gelöscht und eingefügt wird, können auch regelmäßige Index- / Tabellenrestrukturierungen hilfreich sein für den Anbfragespeed.

[p80286]

Zitat von jobo:

Es scheint sich eher um so eine Art Log zu handeln.

Die typische DB-Anwendung

Zitat von jobo:

Wenn die Detaildaten umfangreich sind, könnte man die Analysedaten auch lokal ablegen und die tägliche Neuabfrage mit den Daten vom Vortag vergleichen. Erst bei Differenzen den Server überhaupt kontaktieren und updaten.

die Idee gefällt

Gruß
K-H

[jobo]

Ich hab aber den Eindruck, dass da was anderes schief läuft. TADODataset auf komplette Detailtabellen oder update / delete where Clause ohne Index Wirksamkeit ergäbe (10)tausende Fullscans, Cursors auf dem Server, immer morgens pünktlich um 9, will ja keine schlecht da stehen, dann erstmal Kaffee holen usw.

[Perlsau]

Mir ist die Notwendigkeit des zahlreichen Löschens ganzer Datensätze noch immer nicht so recht klargeworden. Gehen wir mal davon aus, PC_2145 meldet sich an. Dann findet der Server den gesuchten Datensatz und aktualisiert das Daum, wenn sonst keine Änderungen an diesem PC zu vermelden sind. Das heißt, der PC_2145 holt sich seinen Datensatz, überprüft, ob noch alles aktuell ist und sendet die aktualisierten Daten – gegebenenfalls nur das Datum mit Zeitangabe – an den Server zurück.

Haupttabelle

Id_Computer	Computername	Datum
1	PC_2145	01.12.2012 09:26:00
2	PC_3841	01.12.2012 09:26:01
3	PC_1678	01.12.2012 09:26:03
4	PC_4644	01.12.2012 09:26:07

Hardwaretabelle

Id_Hardware	Hardwarename
1	Drucker xy
2	Scanner Soundso
3	USB-Platte Rasant 1374
4	Cardreader Tx4711

Softwaretabelle

Id_Software	Softwarename
1	Software 01
2	Software 02
3	Software 03
4	Software 04

Relation-Tabelle Hardware

Id_Computer	Id_Hardware
1	2
1	4
2	1
2	2
2	3
3	4
2	1
4	2
4	3

Relation-Tabelle Software

Id_Computer	Id_Software
1	1
2	3
2	4
3	2
4	2
4	3

Da muß ich doch nicht jedesmal was löschen, außer ein User hat sich von einer Hard- oder Software getrennt. Ansonsten muß nur das Anmelde-Datum aktualisiert werden. Wenn es z.b. um Kontrolle der Arbeitszeit geht, kann man das dann ebenfalls in einer Relation-Tabelle dauerhaft z.B. für ein Jahr speichern, so daß man alle An- und Abmeldezeiten aller Angestellten auflisten kann.