Glorf IT

Diese Vorführung einer Software vom M IT finde ich ziemlich beeindruckend. OK, nicht so futuristisch, wie das von neulich aber dennoch sehr sehenswert:

Quasi ergänzend zu den gestrigen Postings über Pivoting und den SQL-Hike habe ich auch noch einen Link auf ein kostenloses Probekapitel aus dem Buch "Microsoft SQL Server 2005 T-SQL Querying" von Itzik Ben-Gan, Lubor Kollar, Dejan Sarka und Kalen Delaney rausgesucht. In dem Kapitel Inside Chapter 06 – Aggregating and Pivoting Data geht es um Pivoting und CLR-Funktionen. Wenn meine Leseliste nicht schon so lang wäre, würde ich mir das Buch sofort besorgen… 🙁

Vielleicht sollte ich es trotzdem tun und nur bei Bedarf nachschagen. 😉

Beim SQL Server 2005 kann bekanntlich die Systemtabellen nicht direkt Zugreifen und schon gar bearbeiten. Man sieht sie noch nicht mal. Die "echten" Systemtabellen stehen auch nicht mehr in der Master-Datenbank, sondern in der versteckten Datenbank MsSqlSystemResource. Man kann deren Dateien im Data-Verzeichnis sehen, das ist aber auch schon alles: mssqlsystemresource.mdf/ldf.

Stattdessen gibt es jede Menge Views, die man für den lesenden Zugriff nutzen kann:

• Die guten alten "Systemtabellen" von früheren Versionen werden als Views abgebildet, z.B. sysobjects. Allerdings enthalten die Views keine Informationen über neue Features, einige Attribute, die nicht mehr zutreffende Infos enthalten würden enthalten immer NULL.
• Die ANSI-Views gibt es weiterhin, z.B. INFORMATION_SCHEMA.TABLES. Hier hat sich meines Wissens nichts geändert.
• Die neuen System Management Views, die die alten Systemtabellen ablösen sollen, z.B. sys.objects. Sie sind vergleichsweise sprechend und lehnen sich sehr stark an die alten Systemtabellen an. Sie gefallen mir ganz gut.
• Die neuen Dynamic Management Views enthalten alle möglichen Laufzeitinformationen. So etwas gab es früher auch schon, z.B. die ehemaligen sysprocesses. Ein Beispiel für die Neuen ist sys.dm_exec_connections. Hier stehe ich noch am Anfang, aber das Konzept gefällt mir.

Bei meinem Bestreben die internen Abläufe des Systems zu verstehen waren mit beim SQL-Server immer die Quelltexte der Systemproceduren bzw. die View-Definitionen sehr hilfreich. Lange Zeit dachte ich, es gäbe keine Möglichkeit mir die Definitionen der Systemviews anzusehen. Aber im SQl-Server-Magazine las ich neulich, wie es geht: mit der Funktion "object_definition".

-- Definition von System-Objekten ansehen:
SELECT object_definition(object_id('dbo.sysobjects'))

Damit man im "SQL Server Management Studio" wirklich etwas sehen kann, sollte man die Ergebnisse als Text ansehen im Menü "Query | Results To | Results To Text" oder mit Strg+t und die maximal dargestellte Zeichenzahl pro Spalte auf 8192 setzen.
Dazu im Menü unter "Tools | Options" im Fenster "Options" links "Query Results | SQL Server | Results To Text" für den Wert "Maximum number of characters displayed in each column" den Wert "8192" wählen.

Dem Feature "Pivoting/Unpivoting" stehe ich etwas zwispältig gegenüber: Einerseits habe ich in der Vergangenheit schon mehrfach die Anfrage von Entwicklern bekommen, wie man sowas macht (meist noch in den späten 90ern als wir von Btrieve auf Sybase SQL-Anywhere umstellten). Andererseits sind die zugrundeliegenden Ursachen in der Regel eine "schlechte" Datenmodelierung: Wert-Tabellen, wie sie ein index-sequentiellen Systemen üblich waren. Ich bevorzuge echte relationale Datenmodelle.

In den letzten Jahren habe ich aber auch erlebt, dass es mindestens eine Situation gibt, bei der man um solche Tabellen nicht rumkommt: Wenn man mit relationalen Mitteln eine Art OLAP-System nachbilden will, dann ist es sinnvoll alle möglichen "Fakten" in der gleichen Tabelle unterzubringen und deren Werte im gleichen Feld zu speichern. Damit kann man dann sehr einfach, sehr flexible Auswertungsmöglichkeiten schaffen. Mein Kollege Michael brauchte ziemlich lange, um mich davon zu überzeugen… 😉

Die Werte aus einer Werte-Tabelle werden in eine echte Tabellen übertragen.
Dabei bekommen die einzelnen Attribute auch gleich sinnvolle Namen, z.B. wird "attr1" zu "Typ", "attr2" zu Datum" "attr3" zu "Anzahl" usw.

Der entsprechende PIVOT-Befehl geht so:

SELECT ObjectID, attr1 as Typ,
attr2 as Datum, attr3 as Anzahl,
attr4 as Dings, attr5 as Bums
FROM OpenSchema
PIVOT( Max("Value")
FOR Attribute IN ("attr1", "attr2", "attr3", "attr4", "attr5")
) AS pvt
ORDER BY ObjectID

Wenn man das Bedürfnis hat genau den umgekehrten Weg zu gehen: aus einer normalisierten Tabelle die Ergebnisse in Form einer Wert-Tabelle zu bekommen, dann geht das mit UNPIVOT:

SELECT ObjectID, Attribute, "Value"
FROM ( SELECT ObjectID, cast(Typ as sql_variant) as attr1, cast(Datum as sql_variant) as attr2, cast(Anzahl as sql_variant) as attr3, cast(Dings as sql_variant) as attr4, cast(Bums as sql_variant) as attr5
FROM FixSchema) as "Value"
UNPIVOT
(
"Value"
FOR Attribute IN ("attr1", "attr2", "attr3", "attr4", "attr5")
) AS pvt
ORDER BY ObjectID

Wer noch genug hat: Eine besonders gute Darstellung des Pivotierens liefert wieder mal Itzik Ben-Gan. Die Folien von seinem Vortrag "Advanced T-SQL Techniques" zur TechEd 2006 in Israel stehen bei microsoft.com (siehe "Advanced T-SQL Techniques"). Ich glaube, sie sind auch ohne seinen Text verständlich. Als ich ihn 2005 in London persönlich erleben durfte, zeigte er ganz ähnliche Folien. Deswegen bin ich da nicht repräsentativ.

Peter machte mich auf den recht netten Artikel Fränkische Schweiz „Wie hart wollt ihr es haben?“ auf sueddeutsche.de aufmerksam.

Da schildert ein Reporter seine erste Höhlentour. Er befuhr die Schönsteinhöhle und war ganz offensichtlich beeindruckt… 😉

Im TechEBlog wird ein Filmchen gezeigt in dem man einer "offenen" Festplatte bei der Arbeit zusehen kann. Echt nett: Hard Drive Exposed

Gestern gab mir ein Kollege die Ausgabe 9/2005 vom SQL Server Magazine (ich stehe auf dem Umlauf). Er hatte sie in seinem Schrank entdeckt. Seitdem wir eine Clean-Desk-Philosophie haben, müssen wir alles in den Schrank räumen, wo er sie vergessen hat…

Dennoch bin ich dafür dankbar, das er die Ausgabe weitergegeben hat, denn sie enthält mehrere für mich wichtige Artikel. Eine ganz interessante Sache hätte ich in der Feature-Flut des SQL-Servers-2005 sonst glatt übersehen: Included-Columns.

Wer schon mal erlebt hat, wie man eine Abfrage durch Index-Covering beschleunigen kann, der wird meine Begeisterung teilen. Index-Covering beschreibt den selten auftretenden Fakt, dass in der Abfrage sowohl im WHERE- als auch im SELECT-Teil (und überhaupt im gesamten SELECT-Statement) ausschließelich Attribute zugegriffen werden, die in einem (zusammengesetzten) Index verwendet werden. In diesem Fall muss der SQL-Server gar nicht erst die Datenseiten der Tabelle lesen, es reicht den Index auszuwerten. Damit kann locker die Performance verdoppelt werden, meist noch mehr.

Für Non-Clustered-Indexes können am SQL Server 2005 zusätzlich zu den Attributen, die Bestandteil des Index sind, weitere rein beschreibende Attribute beigegeben werden. Deren Werte werden dann nicht im Index-Baum/-Pfad gespeichert, sondern nur in der Leaf-Page. Sie werden bei Index-Covering aber gezielt verwendet.

Risiken und Nebenwirkungen:

• Speicherplatz
• Performance bei ändernden Operationen
• positiv: Umgehung der "900-byte maximum key column size limitation"

Heute habe ich bei awprofessional.com auch noch einen Artikel zu dem Thema entdeckt: SQL Server 2005: Two Little Known Features That Matter Big! Including Non-Key Columns in Non-Clustered Indexes. Dort stehen auch ein paar sehr gute Beispiele, ebenso in den Books-Online weshalb ich sie mir an dieser Stelle spare.

Da wäre ich aus verschiedenen Gründen gerne dabei gewesen… Seufz
SQL-Hike….

Die Gegend, die Leute, echter Urlaub, … Seufz …

Bei yukonxml.com gibt es eine nette Sammlung mit Werbe-Kapiteln aus Büchern zum SQL Server 2005. Dabei findet sich etwas für jeden Geschmack.

Bei Gulp wurden die Antworten von 106 Projektanbietern ausgewertet welches Verhalten eines IT-Freiberuflers führt dazu, dass der Projektanbieter nicht mehr mit ihm zusammenarbeiten möchte. Das finde ich sehr spannend, weil in unserer Firma seit Jahren einige Freiberufler tätig sind.

Die genannten Gründe sind meiner Ansicht gut nachvollziehbar:

• Hält Interview-Termin nicht ein (wäre für mich auch der absolute Killer: Wer schon zum ersten Termin nicht oder zu spät kommt, wie ist es dann erst mitten im Projekt?)
• Will mit dem Kunden direkt zusammenarbeiten (und mich damit ausbooten – na klasse, so einer macht sich beliebt)
• bricht das Projekt ab, wei er etwas besseres findet (kann es einen besseren Beweis für Unzuverlässigkeit geben?)

Den Punkt "Ist zwischenmenschlich kompliziert" hätte mit 30% nicht so hoch geschätzt. In meinen 13 Jahren Berufserfahrung habe ich es mehrfach erlebt, dass keine weiteren Projekte mehr vereinbart wurden, weil die fachliche Qualifikation nicht den Erwartungen entsprach. Aber ich kann mich jetzt an keinen Fall erinnern, wo es an den zwischenmenschlichen Erfahrungen gescheitert wäre.
Na gut, ich erinnere mich an einen Externen, der ständig das Fenster aufgerissen hat und mit seinem Freilufttrieb die anderen Kollegen im Zimmer in der kalten Jahreszeit gegen sich aufbrachte. Vielleicht habe ich weitere Vorfälle schlicht verdrängt.

Den kompletten Artikel findet man bei gulp.de: "Umfrage-Ergebnis: Verspielte Projektchancen"

In meiner privaten Online-Abstinenz wurde ich beim Stöbern in meinen dienstlichen Quellen heise.de und Golem.de wieder auf das Thema "Mit 40 zum alten Eisen" aufmerksam.

Besonders interessant finde ich den Absatz:

Durch ihr Verhalten würden viele ältere Führungskräfte die Ausbootung allerdings unfreiwillig sogar noch unterstützen. "Wer bei Meetings immer nur sagt "'"Das hat schon vor zehn Jahren nicht geklappt"'", nutzt seinen Erfahrungsschatz zu destruktiv", kritisiert der Manager.

"Er muss sich dann nicht wundern, wenn er mit der Zeit als unflexibler Quertreiber dasteht – und damit gängige Altersstereotype wie Starrköpfigkeit unterstützt oder gar generiert."

Die richtige Reaktion in so einer Situation wäre demnach zu sagen: "Vor 10 Jahren hat das nicht geklappt. Wenn wir dies und das besser machen, dann lernen wir aus den Fehlern des letzten Versuchs."

Als ich den Beitrag " ältere Mitarbeiter: Ballast oder wichtige Know-how-Träger?" schrieb, war mir noch nicht klar, dass ich sooo bald auch dazu gehöre… 😉

Michael schickte mir beiliegendes Bild, dass ich sehr gelungen finde.
Leider ist es eine Fälschung, wie man popularmechanics.com nachlesen kann. Wenn man genau hinschaut, dann erkennt man die Manipulationen sogar.