Ist es vorteilhaft, bei der Verwendung von Linq to SQL mehrspaltige (zusammengesetzte) Primärschlüssel für eine Tabelle mit vielen Beziehungen zu verwenden?
Oder sollte ich einfach eine Identitätsspalte als nicht geclusterter Primärschlüssel hinzufügen und die FK-Spalten entsprechend indizieren?
Nicht ein LINQ-Problem. Wenn Sie sie für Ihr Schema benötigen, dann verwenden Sie sie. Wenn nicht, lassen Sie es. So oder so, LINQ wird Ihr Schema sehr gut verarbeiten.
Ein Bereich, den LINQ to SQL nicht gut handhabt, sind Mapping-Tabellen mit mehreren Spalten/Schlüsseln, die verwendet werden, um eine viele-zu-viele-Beziehung zu verbinden, aber ich würde nicht sagen, dass dies streng unter die Kategorie fällt, die Ihre Frage anspricht. Sie können immer noch CRUD-Operationen auf einer Mapping-Tabelle innerhalb von LINQ durchführen, aber LINQ kann die Beziehung, die durch eine Many-to-Many-Mapping-Tabelle dargestellt wird, nicht durchlaufen. (LINQ funktioniert gut mit Eins-zu-Eins- und Eins-zu-Vielen-Tabellen).
Ich kann nicht auf ein Problem mit dem Entity Framework sprechen, aber auch hier wäre ich sehr überrascht, wenn das EF irgendwelche Probleme mit mehrspaltigen / Multischlüsseltabellen hätte.
Wenn es in Ihrer Domäne sinnvoll ist, einen mehrspaltigen zusammengesetzten Schlüssel zu haben, dann verwenden Sie einen. Andernfalls verwenden Sie die übliche Identitätsspalte als Surrogat-Primärschlüssel.
EDIT: Das war ein allgemeiner Ratschlag und berücksichtigt keine technischen Aspekte der Implementierung mit LINQtoSQL. Diese könnten von Interesse sein:
Wie man: Umgang mit zusammengesetzten Schlüsseln in Abfragen (LINQ to SQL)
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
