Enterprise 2.0 und wie das mit meinem ADC-Beitritt zusammenhängt

Ab und an sollte man auch mal was Neues ausprobieren, und so bin ich gestern der Apple Developer Connection beigetreten. Eine kostenfreie Online-Mitgliedschaft zwar nur, aber für erste Schritte mit XCode und dem iPhone SDK wird es reichen. Ich bin sehr neugierig auf die Qualität der Frameworks, und war überrascht, wieviel Videomaterial und Dokumentation Apple einem zur Verfügung stellt. Ich habe schon viele Entwicklungsplattformen ausprobiert, aber hier fühlt man sich von Anfang an blendend betreut. Ich mag das:

adc2008

Wofür das Ganze? Ich denke derzeit darüber nach, ob das iPhone auch für Enterprise-ApplikationenSinn macht. Mir war dabei nicht klar, wie ich Anwendungen „auf den Firmenrahmen begrenzt“ auf Smartphones ausrollen kann. Klar, es gibt den iTunes AppStore um selbstentwickelte Programme auszurollen, aber ich denke nicht, dass ich über kurz oder lang ein eigenes Programm auf den freien Markt werfen will. Was Applikationen Im Firmen-Extranet angeht sieht es da schon wieder anders aus. Und hierfür möchte ich Smartphone und Netbookansätze unbedingt ausprobieren.

Ein anderer Gedanke: Auf dem Enterprise 2.0 Forum, dass ich diese Woche in Köln besucht habe, wurde mehrmals angesprochen, dass Computer und Smartphones immer mehr in das Privateigentum der Mitarbeiter übergehen werden. Das hätte etwas mit der Bequemlichkeit der Leute zu tun, die nicht 2-3 mal das selbe Gerät mitschleppen wollen. Firmen stellen ihre Arbeitsplattformen ohnehin mehr und mehr via Internet bzw. Extranet zur Verfügung, das individuell genutzte Gerät spielt damit immer weniger eine Rolle. Da Reisekosten immer mehr steigen, die Welt aber zeitgleich immer globaler wird, werden mehr und mehr Mitarbeiter ihre Arbeit „fern von der Firma“ erledigen. Da es darüber hinaus in Mode kommt, Zielerfüllung statt Stundenzahl zu honorieren, steigt die Anzahl der Jobs die ein einzelner Mensch ausführen wird. Sicher gilt das nicht für jedes Feld, aber ein Trend ist da.

Als abschließendes illustrierendes Beispiel haben wir gehört, dass Anfang des vorigen Jahrhunderts Mitarbeiter in Banken nur die Federkiele und Tinten der Bank nutzen durften, damit in den Büchern ein einheitliches Schriftbild herrschte. Davon ist ziemlich wenig übriggeblieben: Ich denke wir haben alle unsere eigenen Kugelschreiber inzwischen. Ich werde jedenfalls auf Weihnachtsgeschenke meiner Familie im Job nicht verzichten.

MS SQL Server kennenlernen – Tag für Tag

Als Ergänzung zu meinem Eintrag von gestern, mag ich hier noch einmal kurz auf die SQL Server Central Community eingehen. Das ist nämlich der perfekte Ort, um MS SQL Server jeden Tag ein klein wenig besser kennenzulernen.

Neben Artikeln und einem breiten Angebot an Foren haben es mir dort besonders die Fragen des Tages(QOTDs – Question of the Day) angetan, die einen regelmässig auf die Seite zurückziehen. Da es dabei auch Punkte gibt, kann man sich über die Zeit leicht mit anderen DBAs und Entwicklern messen. Doch gerade falsche Antworten sind lehrreich: Die Seite weist in diesem Fall auf die entsprechenden Einträge im Microsoft Developer Network (MSDN) hin.

Auf diese Art geht lernen schnell und macht auch noch Spaß. Einziger Nachteil: man muss seine Email registrieren.

Der zugehörige Link: Welcome to SQL Server Central.

MS SQL Server: Einfach zu einfach?

In meinem Entwickler-Alltag spielt der Microsoft SQL Server oft eine sehr wichtige Rolle und das schon seit der katastrophal fehlerträchtigen Version 6.0. Zwar habe ich auch mit anderen Datenbanken wie beispielsweise DB2Oracle  oder MySQL zu tun, aber der MS SQL Server hat spätestens seit der stabilen 2000er-Version eine Sonderstellung und ist ein Werkzeug, dem ich einfach überall begegne.

Das hat meiner Meinung nach zwei Gründe:

  1. MS SQL Server ist kinderleicht ans Rennen zu kriegen
  2. er wird mehr und mehr zum Komplett-Paket für alle Business Intelligence Belange, und ist (zumindest wenn man einen Großteil der gelieferten Funktionalität auch wirklich einsetzt) einfach kostenmäßig extrem attraktiv.

Der erste Punkt, die problemlose Einrichtung, ist jedoch nicht ganz ungefährlich: Die Einstiegsanforderungen an einen Datenbank-Administrator (kurz: DBA) sind sehr gering, ich kenne sogar Firmen, die auf die dedizierte Rolle DBA weitestgehend verzichten. Stösst man aber irgendwann an die Grenze, an der die Standardkonfiguration ausgereizt ist, wird es ohne DBA schnell kritisch.

Es ist also Vorsicht geboten. Ich möchte darum in diesem Artikel ein paar der Fallstricke aus meinem Projektalltag knapp umreissen.

Es fängt oft mit Trivialitäten an. Die erste Klippe ist der vorhandene Arbeitsspeicher. Solange dieser groß genug ausfällt, ist es möglich, auch mit größeren Tabellen halbwegs performant auszukommen, und das selbst wenn kein einziger Index definiert wurde.

Geht die Performance dann bei steigendem Datenvolumen irgendwann in den Keller, ist das eine Klippe, die man meist mit Programmierern noch lösen kann. Indizes kriegen Entwickler selbstverständlich noch gut in den Griff. Die wenigsten Entwickler kennen jedoch die breite Werkzeugpalette innerhalb MS SQL Servers, die sich diesem Problem analytisch und zum Teil sogar automatisch annimmt.

Sind die Index-Probleme einmal gelöst, kommt bald eine neuer Eisberg auf uns zu. Auf 32Bit-Systemen ist diese Grenze dann erreicht, wenn die erste Tabelle mehr als 2GB Daten umfasst. Ab diesem Punkt spätestens muckt SQL Server auf: Wir haben den Adress-Raum eines 32-Bit-Systems verlassen, einfachste Operationen auf der Tabelle werden langwierig und spannend wie eine Herz-OP, und nichts ist mehr eitel Sonnenschein. Ich sage nicht, dass diese Klippen nicht zu umschiffen sind, aber ab diesem Punkt werden echte DBA-Kenntnisse unabdingbar. Programmierer kriegen diese Problematik in der Regel nicht mehr in den Griff. Es ist einfach kein Software-Problem mehr; ein Index als Zugriffspfad hat noch etwas Entwickler-Nahes, aber die schnöde Probleme Arbeitsspeicher und Plattenplatz haben meiner Meinung nach nichts in Programmierer-Hand zu suchen.

Fazit: Microsoft SQL Server ist kinderleicht einzuführen, das stimmt. Aber man sollte von Anfang an eine DBA Rolle einführen, auch wenn sie zunächst unnötig erscheint.

Ein guter DBA kennzeichnet sich meiner Meinung nach dadurch, dass man seine Arbeit nicht bemerkt. Fehlt er aber, wird das im Falle von MS SQL Server mit gefährlicher Verzögerung offensichtlich. Oft sind eingeführte Systeme dann schon unternehmenskritisch geworden… es ist also Vorsicht geboten!

Es gibt viele Schrauben im Hintergrund von MS SQL Server, aber wenn man sich regelmässig und gewissenhaft mit ihnen beschäftigt, erhält man auch ein auf Dauer stabiles und performantes System.

Links zum Artikel: