Glorf IT

Neulich erzählte ein Kollege, dass in seinem Team ziemlich viele Kolleginnen und Kollegen gesundheitliche Probleme haben. Sie führen das auf die anhaltend hohe Arbeitsbelastung zurück. Vertreten war Tinnitus (mehrfach), Bandscheibenvorfall, Schlafstörungen und psychische Probleme (wenn ich mich richtig erinnere). Damals dachte ich noch, dass ich in dem Team nicht gerne wäre. Interessant fand ich auch, dass unser Boss das primär als Führungsproblem im Team ansah.

In der Süd-Deutschen-Zeitung steht jetzt ein Artikel ("Unsinn Überstunde") zu diesem Thema drin, der den Zusammenhang zwischen Überstunden (=Arbeitsbelastung?) und Gesundheitsschäden sehr gut belegt.

Wie viele Untersuchungen zeigen, steigen die Beschwerden mit der Wochenarbeitszeit an. Rücken- und Magenschmerzen, Schlafstörungen und Herzprobleme nehmen zu. Die Leistungsfähigkeit leidet. Unternehmen, die ihre Mitarbeiter dazu anhalten, möglichst lange zu arbeiten, schaden sich damit selber.

Aus eigener Erfahrung kann ich eine Feststellung bestätigen:

Schon ab der siebten Stunde fällt die Leistungsfähigkeit ab, die Fehleranfälligkeit nimmt zu. Bei der Wochenarbeitszeit ist nach 35 bis 38 Stunden Ende der Fahnenstange.

Daher mache ich am späten Nachmittag nach Möglichkeit am liebsten Routinetätigkeiten bei denen ich nicht viel nachdenken muss. Späte Anfragen oder Hilfegesuche kosten mich erheblich mehr Kraft als am nächsten Morgen.

Gestern las ich bei coreworxx den Artikel "UPDATE Trigger – schon mal reingefallen?" und wollte auch gleich einen Kommentar schreiben. Weil ich dazu aber einen Google-Account einrichten müsste, antworte ich lieber hier und setze einen Trackback…
Schade, weil ich jetzt erst mal den Kontext herstellen muss, damit man nicht erst den einen Artikel lesen muss, um diesen zu verstehen. Übrigens liebe ich es Artikel über SQL-Themen zu lesen: also bitte nicht abschrecken lassen…

Andreas Gümbel beschreibt in dem Artikel, wie man mittels der Tabellen INSERTED und DELETED mitbekommt wie die Werte des geänderten Datensatzes vor und nach der Änderung kommt. Hier eines seiner Beispiele:

CREATE TRIGGER [TRIGGER_NAME_Update] ON [dbo].[myTableName]
FOR UPDATE
AS
DECLARE @myInsertId int
SELECT @myInsertId=myTableId FROM INSERTED
[weitere Verarbeitung …]

Das ist völlig korrekt beschrieben.
Aber dennoch würde ich von diesem Statement abraten. Es geht strikt davon aus, dann immer nur ein einziger Datensatz geändert wird. Um die optimale Performance zu erreichen werden in Datenbanksystemen aber immer möglichst alle betroffenen Datensätze mit einem Schwupps geändert.
Ich merke immer wieder, dass es gerade altgedienten Programmierern schwer fällt, dass man jetzt nicht mehr mühsam alles über eine Schleife machen muss: In SQL macht man das mit einem einzigen Befehl. Hier mein Lieblingsbeispiel: Alle Mitarbeiter der Datenbankbetreuung bekommen eine 10%ige Gehaltserhöhung…

UPDATE Stammdaten.Mitarbeiter
SET Gehalt = Gehalt * 0.1
WHERE team='Datenbanktechnologie'

Das Statement dauert fast genau so lange wie der Update eines einzelnen Datensatzes. Deswegen macht man eher selten einen Update auf einen Satz. Und selbst wenn man jetzt fest überzeugt ist, dass man niemals mehrere Sätze gleichzeitig wird. Sollte man das dennoch vorsehen, weil sich meiner Erfahrung nach sehr schnell die Randbedingungen ändern und "Puff" knallt der Trigger mitten im laufenden Betrieb an die Wand.
Das ist übrigens eine Tuningmaßnahme, die ich immer wieder bei Performanceanalysen empfehlen muss: Mengenupdates anstelle von Schleifen. In der ersten Runde geht es meist auf gar keinen Fall, weil man ja in dem jeweiligen Objekt keine Infos darüber hat, welche anderen Objekte sonst noch betroffen sind. Wenn der Druck von Seiten der Kunden steigt, geht es meistens doch…

Daher: Im Trigger selber bitte immer die Verarbeitung von mehreren Datensätzen vorsehen.