sql - Timer

Translate

Ich arbeite derzeit an einem Projekt mit spezifischen Anforderungen. Ein kurzer Überblick über diese ist wie folgt:

  • Daten werden von externen Webservices abgerufen
  • Die Daten werden in SQL 2005 gespeichert
  • Daten werden über eine Web-GUI bearbeitet
  • Der Windows-Dienst, der mit den Webdiensten kommuniziert, ist nur über die Datenbank mit unserer internen Web-Benutzeroberfläche gekoppelt.
  • Die Kommunikation mit den Webdiensten muss sowohl zeitbasiert als auch durch Benutzereingriffe auf der Web-Benutzeroberfläche ausgelöst werden.

Das aktuelle Modell (vor der Produktion) für das Auslösen der Webdienstkommunikation erfolgt über eine Datenbanktabelle, in der Auslöseanforderungen gespeichert werden, die aus dem manuellen Eingriff generiert wurden. Ich möchte nicht wirklich mehrere Auslösemechanismen haben, möchte aber in der Lage sein, die Datenbanktabelle basierend auf dem Zeitpunkt des Aufrufs mit Auslösern zu füllen. Aus meiner Sicht gibt es zwei Möglichkeiten, dies zu erreichen.

1) Passen Sie die Triggertabelle an, um zwei zusätzliche Parameter zu speichern. Eine davon ist "Ist dies zeitbasiert oder manuell hinzugefügt?" und ein nullbares Feld zum Speichern der Zeitdetails (genaues zu bestimmendes Format). Wenn es sich um einen manuell erstellten Trigger handelt, markieren Sie ihn als verarbeitet, wenn der Trigger ausgelöst wurde, nicht jedoch, wenn es sich um einen zeitgesteuerten Trigger handelt.
or
2) Erstellen Sie einen zweiten Windows-Dienst, der die Trigger in zeitlichen Abständen im laufenden Betrieb erstellt.

Die zweite Option scheint mir ein Unsinn zu sein, aber die Verwaltung von Option 1 könnte leicht zu einem Programmier-Albtraum werden (woher wissen Sie, ob die letzte Abfrage der Tabelle das Ereignis zurückgegeben hat, das ausgelöst werden muss, und wie stoppen Sie es dann? bei der nächsten Umfrage erneut auslösen)

Ich würde es begrüßen, wenn jemand ein paar Minuten Zeit hätte, um mir bei der Entscheidung zu helfen, welche Route (eine dieser beiden oder möglicherweise eine dritte, nicht aufgeführte) zu nehmen ist.

This question and all comments follow the "Attribution Required."

Alle Antworten

Translate

Warum nicht einen SQL-Job anstelle des Windows-Dienstes verwenden? Sie können Ihren gesamten Datenbank-Triggercode in gespeicherte Prozeduren einkapseln. Dann können Ihre Benutzeroberfläche und Ihr SQL-Job dieselben gespeicherten Prozeduren aufrufen und die Trigger auf dieselbe Weise erstellen, sei es manuell oder in einem Zeitintervall.

Quelle
Translate

So wie ich das sehe, ist das so.

Sie haben einen Windows-Dienst, der die Rolle eines Schedulers spielt, und darin gibt es einige Klassen, die einfach die Webservices aufrufen und die Daten in Ihre Datenbanken einfügen.

Sie können diese Klassen also auch direkt über die WebUI verwenden und die Daten basierend auf dem WebUI-Trigger importieren.

Ich mag die Idee nicht, eine vom Benutzer generierte Aktion als Flag (Trigger) in der Datenbank zu speichern, wo ein Dienst sie abfragt (in einem Intervall, das nicht unter der Kontrolle des Benutzers steht), um diese Aktion auszuführen.

Sie können sogar den gesamten Code in eine Exe konvertieren, die Sie dann mit dem Windows Scheduler planen können. Rufen Sie dieselbe Exe auf, wenn der Benutzer die Aktion über die Web-Benutzeroberfläche auslöst.

Quelle
Translate

@ Vaibhav

Leider erlaubt die physische Architektur der Lösung keine direkte Kommunikation zwischen den Komponenten außer der Web-Benutzeroberfläche zur Datenbank und der Datenbank zum Dienst (die dann die Webdienste aufrufen können). Ich stimme jedoch zu, dass die Wiederverwendung der Kommunikationsklassen hier ideal wäre - ich kann es einfach nicht innerhalb der Grenzen unseres Geschäfts tun *

* Ist es nicht immer so, dass eine technisch "bessere" Lösung durch externe Faktoren behindert wird?

Quelle