ADO.NET - Datenbankprogrammierung

Veröffentlicht: 25. Sep 2002 | Aktualisiert: 10. Nov 2004

Von Ralf Westphal

Quelle: Addison-Wesley

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?
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).

"Mit automatischen Primärschlüsseln leben" aus "ADO.NET - Datenbankprogrammierung" als PDF lesen

Diesen Beitrag hat uns freundlicherweise Addison-Wesley zur Verfügung gestellt, ein Partner von MSDN Online.