Glorf IT

Heute erst las ich bei Heise den Aufruf des CCC (Chaos Computer Club) der problematischen Randgruppe "Politiker" genau auf die Finger zu schauen. Die Argumente überzeugen mich mindestens so sehr wie die Absicht Anderer das Internet und deren Nutzer stärker zu observieren:

Angesichts der vielen Berichte über schwarze Kassen handle es sich schließlich um potenzielle Straftäter, bei denen Maßnahmen zur Gefahrenabwehr zu treffen seien. "Politiker bestechen und drücken Gesetze durch, damit Firmen mehr Geld kriegen", ergänzte CCC-Veteran Frank Rieger. Im kommenden Jahr müsse daher eine "ordentliche Datensammlung über alle Politiker" aufgebaut werden, diese hätten schließlich prinzipiell "nichts zu verbergen".

Bei "The Code Project" wurde letzte Woche ein interessantes Projekt veröffentlicht: Mittels DotNet-Methoden werden BLOB-Daten ("Binary Large OBject") komprimiert gespeichert: Mit Hilfe der Funktionen fn_compress und fn_decompress werden die BLOBs geschrumpft oder aufgepustet.

Ich finde die Idee sehr interessant, aber habe auch Bedenken.
Das ist eine gute Möglichkeit den Leistungsumfang von SQL mittels CLR zu erweitern und eine Aufgabe zentral zu erledigen. Andererseits kostet das wertvolle CPU-Zeit am Server. Wenn man sehr keine und dumme Clients hat, dann ist das sicher trotzdem ein gute Wahl. Wenn ich normale PCs als Clients habe, dann lohnt es sich sicher die Daten schon vor der Übertragung zu komprimieren. Dann schont es Bandbreite im Netz und die CPU des Servers wird geschont.

Wenn man es schon so machen will, dann würde ich die Lösung erweitern: Man kann einen neuen Datentyp schaffen, der die Komprimierung und Dekomprimierung ohne explizitem Befehl erledigt. Dazu muss man lediglich die Methoden zur Serialisierung bzw. dem Lesen der Daten entsprechend programmieren.

Details stehen im Artikel "Using CLR integration to compress BLOBs/CLOBs in SQL Server 2005".