Aug 312010
 

Bei meinen ersten Gehversuchen mit dem Entity Framework bin ich natürlich gleich über die erste Hürde gestolpert:
Da ich weder mit Kanonen auf Spatzen schießen wollte, noch externe Libs=Fehlerquellen einbinden wollte, startete ich mit dem MS SQL Server in der Compact Edition. Soweit so gut, dank EF gelang die DB-Erstellung recht mühelos direkt aus VS2010 und die große Datenmodellierungsorgie konnte beginnen…
Aus alter Gewohnheit bekam jede Tabelle eine int-Spalte ID, die via Auto-Inkrement implizit für jeden neuen Datensatz befüllt werden sollte. Zur Laufzeit, beim Versuch generierte Daten zu persistieren, dann der erste Dämpfer, dankenswerterweise mit wirklich aussagekräftiger Exception:

„No support for server-generated keys and server-generated values“

Was solll das? Ganz einfach: die Compact Edition streikt einfach schon bei einer so einfachen Funktion wie dem Hochzählen der ID. „Unverschämtheit“ war mein erster Gedanke, ist die Tradition brauchbarer Gratis-DBs à la MSDE etwa Vergangenheit? Wie soll ich mit einer DB arbeiten, die so rudimentär ist, dass sie nichtmal die einfachsten Funktionen beherrscht? Kurz hab ich sogar überlegt, selbst die nächste unbenutzte Int-ID zu berechnen, hatte aber eigentlich keine Lust darauf, wollte ich doch das EF nutzen, um mir eben keinen DataAccess-Layer händisch coden zu müssen. Zum Glück konnte ich diese Überlegung schnell als überflüssig beiseitelegen, denn es handelt sich wohl eher um eine strategische Entscheidung seitens MS, die Implementierung hat ja nun echt nichts mit „Rocket Surgery“ zu tun.
Vielmehr will MS uns wohl dahin treiben, aus der Not eine Tugend zu machen, und zwar mit…
…Tä-tätä-tää: UUIDs bzw. GUIDs.
Beim Anlegen neuer Objekte reicht folgende Zeile, um eine absolut einzigartige ID zu erzeugen, ohne Buch zu führen, ob sie schon verwendet wurde:
Id = Guid.NewGuid()
Ok, sie liest sich nicht ganz so nett wie eine laufende Nummer, und danach zu sortieren ist auch recht sinnfrei, aber wir wollten ja auch eine eindeutige ID und keinen Zeitstempel und erst recht keinen DisplayName, der an die Oberfläche gelangen soll. Durch Kryptifizierung dieser ID dürften diese Verführungen damit der Vergangenheit angehören – wer einen Zeitstempel braucht, kann dafür ja eine eigene Spalte, entkoppelt von der ID-Funktionalität, spendieren und umgeht somit weitere Probleme.
Das war übrigens auch mal Thema im permanent provozierten Streitgespräch zwischen Golo Roden und Peter Bucher.