LINQ to SQL und Primärschlüssel

27/11/2008 - 15:08 von Patrick Denke | Report spam
Warum ist der SQL-Tabelle eigentlich ein Primàrschlüssel notwendig, wenn
ich mit LINQ to SQL arbeite?

Hintergrund: Ein Kunde hat eine Microsoft SQL Datenbank bereitgestellt mit
2 Tabellen.
Die erste Tabelle enthàlt generell nur jeweils eine Zeile pro Messserie.
Schematisch etwa folgende Spalten (stark verkürzt):
Messung (uniqueidentifier, NOT NULL)
Kennung (char(20),NOT NULL)
MittelwertOben (real, NOT NULL)
MittelwertUnten (real, NOT NULL)

Tabelle 2 soll nun die Einzelmesswerte aus MittelwertOben und
MittelwertUnten enthalten, verknüpft über die Spalte Messung
Messung (uniqueidentifier, NOT NULL) (Soll dieselbe GUID wie oben sein)
Messpunktnummer (int, NOT NULL)
WertOben (real, NOT NULL)
WertUnten (real, NOT NULL)

Tabelle 2 enthàlt also pro Messserie i.d.R. mehr als eine Zeile, je nach
Anzahl der Messpunkte, aber mit identischer GUID in der Spalte Messung.
D.h. in der Spalte Messung können Eintràge mehrmals vorkommen.

Ich wollte nun external Mapping verwenden und habe SQLMetal angeworfen,
aber mit der Fehlermeldung, es sei kein Primàrschlüssel vorhanden.

Also habe ich in beiden Tabellen die Spalte 'Messung' als PS festgelegt.
SQLMetal hat mir dann auch brav die xml- und vb Datei erstellt.
Nun meckert aber VB bei verbindung.SubmitChanges() über DuplicateEntries in
der Tabelle 2.

Wie komme ich aus dem Dilemma heraus, d.h. kann ich auch irgendwie mit LINQ
to SQL ohne Primàrschlüssel arbeiten (wie gesagt, die Tabellen sind
Kundenvorgaben und können von mir nur mit viel bitte bitte in Ihrer
Struktur veràndert werden)

Gruß Patrick
 

Lesen sie die antworten

#1 Elmar Boye
27/11/2008 - 15:23 | Warnen spam
Hallo Patrick,

Patrick Denke schrieb:
Warum ist der SQL-Tabelle eigentlich ein Primàrschlüssel notwendig, wenn
ich mit LINQ to SQL arbeite?



Weil Linq To SQL sonst die Objekte in der Datenbank nicht wiederfinden
kann und es mit dem Anspruch antritt die Daten aktualisieren zu können.
Das gilt im übrigen für alle ORM und auch DataSet und Co.

Hintergrund: Ein Kunde hat eine Microsoft SQL Datenbank bereitgestellt mit
2 Tabellen.
Die erste Tabelle enthàlt generell nur jeweils eine Zeile pro Messserie.
Schematisch etwa folgende Spalten (stark verkürzt):
Messung (uniqueidentifier, NOT NULL)
Kennung (char(20),NOT NULL)
MittelwertOben (real, NOT NULL)
MittelwertUnten (real, NOT NULL)

Tabelle 2 soll nun die Einzelmesswerte aus MittelwertOben und
MittelwertUnten enthalten, verknüpft über die Spalte Messung
Messung (uniqueidentifier, NOT NULL) (Soll dieselbe GUID wie oben sein)
Messpunktnummer (int, NOT NULL)
WertOben (real, NOT NULL)
WertUnten (real, NOT NULL)

Tabelle 2 enthàlt also pro Messserie i.d.R. mehr als eine Zeile, je nach
Anzahl der Messpunkte, aber mit identischer GUID in der Spalte Messung.
D.h. in der Spalte Messung können Eintràge mehrmals vorkommen.



Dann füge in die Tabelle 2 eine zusàtzliche uniqueidentifier (mit NEWID als
Default) oder auch Integer (mit Identity) Spalte ein und erklàre sie zum
(nonclustered) Primary Key.

Damit der Zugriff zügig làuft erstelle zusàtzlich einen (clustered)
Index auf Messung (ggf. inkl Messpunktnummer, wenn das ein Ordnungs-
begriff ist, wie der Name vermuten làßt).

Nun meckert aber VB bei verbindung.SubmitChanges() über DuplicateEntries in
der Tabelle 2.

Wie komme ich aus dem Dilemma heraus, d.h. kann ich auch irgendwie mit LINQ
to SQL ohne Primàrschlüssel arbeiten



Wenn Du die Daten veràndern willst, benötigst Du einen eindeutigen
Schlüssel, da führt kein Weg vorbei.

(wie gesagt, die Tabellen sind Kundenvorgaben und können von mir
nur mit viel bitte bitte in Ihrer Struktur veràndert werden)



Die oben vorgeschlagene Änderung ist im wesentlichen transparent für
bestehende Anwendungen (wenn sie einigermaßen sauber geschrieben sind).

Gruß Elmar

Ähnliche fragen