Stored Procedure oder programmseitiger Filter?

Hallo zusammen,

folgendes Szenario: Wir lesen Transponderdaten aus. Diese Daten werden ausgelesen, so lange sich die Transponder in Reichweite des Lesegeräts befinden. So ca. 8 mal pro Sekunde. Daran lässt sich nichts ändern.
Da für jedes Lesen nur ein Datensatz in eine Datenbanktabelle eingefügt werden soll, arbeiten wir mit einer Stored Procedure. Diese Stored Procedure prüft, ob in der neue Datensatz der eingefügt werden soll innerhalb eines bestimmten Zeitintervalls bereits in der Tabelle vorhanden ist. Wenn dies der Fall ist, wird der Datensatz verworfen, ansonsten eingefügt. Nun kam Kritik auf, dass diese Überprüfung in einer Stored Procdure schlecht ist, wegen zu viel Anfragen und Traffic etc... Wie schlecht ist das wirklich? Mich würden einige Meinungen hierzu interessieren. Danke schonmal für Antworten.

 

AW: Stored Procedure oder programmseitiger Filter?

Ich würde soetwas über einen Trigger lösen, kann mir aber weder einen Geschwindigkeitsunterschied zu einer SP vorstellen, noch einen Geschwindigkeitsnachteil gegenüber einer anderen Lösung, sofern die Prozedur notwendig ist.

Alternativ könnte man die Daten erst rein schreiben und später per Script löschen.

 

AW: Stored Procedure oder programmseitiger Filter?

Hallo sven85,

gibt es mit der Prozedur oder der Datenbank Performance-Probleme?

Der Kritiker soll Dir mal erklären wo bei einer serverseitig ausgeführten Prozedur der zusätzliche Traffic herkommen soll.

Ob du dem Server ein INSERT oder ein EXEC schickst spielt beim Traffic wirklich keine Rolle.
Da wird das EXEC wahrscheinlich noch besser abschneiden.

Sonst gebe ich ukulele absolut recht.

Wenn es die Anwendung zulässt bereinige die Daten zu einer Zeit wenn nicht gearbeitet wird oder wenig los ist.


Gruß Charly