Ich entwerfe diese Datenbank, die eine Geschichte des Angestelltengehalts und der Bewegungen innerhalb der Organisation führen muss. Grundsätzlich hat mein Entwurf 3 Tabellen (ich meine, dort mehr Tische, aber für diese Frage werde ich 3 erwähnen, so ertragen Sie mit mir). Mitarbeitertabelle (enthält das aktuellste Gehalt, Positionsdaten usw.), SalaryHistory-Tabelle (Gehalt, Datum, Grund usw.) und MovementHistory (Titel, Abt., Kommentare). Ich werde Linq zu Sql verwenden, also habe ich gedacht, dass jedes Mal, wenn Mitarbeiterdaten aktualisiert werden, die alten Werte in ihre jeweiligen Verlaufstabellen kopiert werden. Ist das ein guter Ansatz? Soll ich es einfach mit Linq zu SQL oder Triggern machen? Danke für jede Hilfe, Anregung oder Idee.
Schauen Sie sich Ссылка an .
Grundsätzlich schlägt der Artikel vor, dass Sie die folgenden Spalten in den Tabellen haben, für die Sie den Verlauf protokollieren müssen -
%Vor%DateEffective und DateEnd geben zusammen die Zeit an, für die die Zeile gültig war (oder die Zeit, für die ein Mitarbeiter in einer Abteilung war oder die Zeit, für die er ein bestimmtes Gehalt verdient hat).
Es ist eine gute Idee, diese Logik intern in der Datenbank zu halten: das ist im Grunde, warum Trigger existieren. Ich sage dies jedoch sorgfältig, da es viele Gründe gibt, es extern zu halten. Oft ist es - insbesondere bei einer so einfachen Technologie wie LINQ-to-SQL - einfacher, den Code extern zu schreiben. Meiner Erfahrung nach könnten mehr Leute diese Logik in C # / LINQ schreiben, als dies mit einem Trigger richtig funktioniert.
Trigger sind schnell - sie sind kompiliert! Sie sind jedoch sehr leicht zu missbrauchen und machen Ihre Logik zu sehr komplex, so dass sich die Leistung schnell verschlechtern kann. Wenn man bedenkt, wie einfach Ihr Anwendungsfall ist, würde ich mich dafür entscheiden, Auslöser zu verwenden , aber das bin ich persönlich.
Trigger werden wahrscheinlich schneller sein und benötigen keinen "mittleren Mann", um die Aufgabe zu erledigen, wodurch mindestens eine Chance für Fehler beseitigt wird.
Abhängig von Ihrer bevorzugten Datenbank können Sie einfach eine Tabelle verwenden und OIDs darauf aktivieren und zwei weitere Spalten hinzufügen, "Flag" und "Previous". Niemals diese Tabelle aktualisieren, nur einfügen. Fügen Sie einen Trigger hinzu, so dass beim Hinzufügen einer Zeile für Mitarbeiter-Nr. Alle Datensätze mit Mitarbeiter-ID auf "alt" gesetzt werden und der vorherige Wert der neuen Zeilen auf die vorherige Zeile gesetzt wird.
Ich denke, das gehört aus zwei Gründen in die Datenbank.
Erstens, mittlere Ebenen kommen und gehen, aber Datenbanken sind für immer. Dieses Jahr Java EJBs, nächstes Jahr .NET, das Jahr danach etwas anderes. Die Daten bleiben meiner Erfahrung nach.
Zweitens: Wenn die Datenbank überhaupt freigegeben ist, sollte sie sich nicht auf jede Anwendung verlassen müssen, die sie verwendet, um zu wissen, wie sie ihre Datenintegrität erhält. Ich würde dies als ein Beispiel für die Kapselung der Datenbank betrachten. Warum das Wissen und die Pflege der Geschichte auf jedem Kunden erzwingen?
Mit Triggern wird die Migration Ihres Front-Ends zu etwas anderem erleichtert und die Datenbank bleibt konsistent, unabhängig davon, wie Daten eingefügt / aktualisiert / entfernt werden.
Außerdem würde ich in Ihrem Fall die Gehälter direkt in die Gehaltshistorie schreiben - aus Ihrer Beschreibung würde ich keinen Grund sehen, warum Sie den Weg über einen Update-Trigger auf dem Mitarbeitertisch gehen sollten.
Tags und Links triggers database linq-to-sql history database-design