ADO.NET Datenbankprogrammierung

3 Mit automatischen Primärschlüsseln leben (S. 49-50)

Fragestellungen

Kann ADO.NET mit Primärschlüsseln umgehen, die vom Datenbanksystem automatisch vergeben werden?
Wie kommt ein automatisch vergebener PK-Wert für einen neuen Datensatz zurück in eine DataRow?
Gibt es Unterschiede in der Behandlung von automatischen Primärschlüsseln bei MS Access und SQL Server?
Können automatische PKs auch als Fremdschlüssel benutzt werden?

3.1 Die guten alten Zeiten

In Kapitel 2 über objekt-relationales Mapping (ORM) nimmt die Diskussion von Objektidentitäten einen breiten Raum ein: Jedes Objekt, das Sie in einer Datenbank speichern, muss eine eigene persistente Identität (Objekt-ID, OID) bekommen. Diese OID bildet dann den Primärschlüssel (PK) der Tabelle, in der Sie die Zustände der Objekte einer Klasse speichern. OIDs sind unveränderlich und gehören nicht zu den Geschäftsdaten einer Klasse.

Diese Eigenschaften sind für einen PK eigentlich nicht neu. Auch in Ihren bisherigen Datenbankschemata haben Sie PKs sicher schon oft so ausgelegt. Die Unveränderlichkeit eines PK macht es einfacher, die referentielle Integrität von relationalen Daten zu gewährleisten: Wenn sich ein PK nach Zuweisung nicht mehr ändern kann, dann fällt auch kein Aufwand dafür an, Änderungen an andere Datensätze weiterzureichen, bei denen er als Fremdschlüssel (FK) eingetragen ist.

Und dass wirklich keine Änderungen an einem PK stattfinden, gewährleisten Sie am besten, indem Sie keine Tabellenspalte mit Geschäftsdaten (z.B. Kunden- oder Produktnummer) als PK benutzen, sondern Tabellen mit einer speziellen PK-Spalte ausstatten (Surrogatschlüssel).

Für einen solchen PK stellt sich dann natürlich die Frage, woher seine Werte kommen. Als Antwort darauf bieten alle relationalen Datenbanksysteme (RDBMS) spezielle Datentypen für Spalten, deren Werte automatisch vergeben werden sollen; bei MS Access sind das die AutoNumber-, bei MS SQL Server die identity-Spalten. Allgemein kann man diese Art Spalten als Autoincrement-Spalten bezeichnen, weil ihnen immer ein ganzzahliger Datentyp zugrunde liegt und die Spaltenwerte ausgehend von einem Startwert (Seed) für jeden neuen Datensatz um einen festen Betrag (Increment, Step, üblicherweise 1) hochgezählt werden. Das RDBMS sorgt dafür, dass auch bei gleichzeitigem Zugriff von vielen Clients jeder Wert eindeutig ist.

Für die Cursor-basierte Datenbankprogrammierung war diese Philosophie völlig ausreichend und bequem. Als Beispiel hier zwei Tabellen, die jeweils mit einem Autoincrement-PK ausgestattet sind und in einer 1:n-Beziehung stehen:

Wenn Sie ein Cursor-basiertes API wie ADO 2.x benutzen und in beiden Tabellen einen neuen Datensatz anlegen wollen, dann können Sie das sehr einfach tun:

Dim conn As New ADODB.Connection()
conn.Open("...")

Dim rsCust As New ADODB.Recordset()
rsCust.CursorLocation = ADODB.CursorLocationEnum.adUseServer
rsCust.Open("select * from AutoCustomers", conn, _