Tipps bitte: SQL Server Identität vs Schlüssel Unique Identifier bei der Verwendung von Entity Framework

Question

Ich bin in dem Prozess ein ziemlich komplexes System zu entwerfen. Eines unserer wichtigsten Anliegen unterstützt SQL Server Peer-to-Peer-Replikation. Die Idee ist, mehrere räumlich getrennten Knoten zu unterstützen.

Ein zweitrangig ist in der mittleren Ebene ein modernes ORM im Einsatz. Unsere erste Wahl ist immer Entity Framework gewesen, vor allem, weil der Entwickler gerne mit ihm arbeiten. (Sie lieben die Linq-Unterstützung.)

So, hier ist das Problem:

Mit Peer-to-Peer-Replikation im Auge, ließ ich mich zur Verwendung von Unique mit einem Standardwert von NEWSEQUENTIALID () für den Primärschlüssel jeder Tabelle. Das schien eine gute Balance zu schaffen zwischen dem Schlüssel Vermeidung von Kollisionen und Indexfragmentierung zu reduzieren.

Es stellt sich jedoch heraus, dass die aktuelle Version von Entity Framework hat ein sehr seltsame Einschränkung : wenn ein Schlüsselspalte des Unternehmens ist eine unique~~POS=TRUNC (GUID), dann kann es nicht den Standardwert zu verwenden (NEWSEQUENTIALID ()) konfiguriert werden, die von der Datenbank zur Verfügung gestellt. Die Anwendungsschicht muss die GUID generiert und den Schlüsselwert füllen.

Also hier ist die Debatte:

1. Entity Framework verlassen und einen anderen ORM verwenden:
   • verwenden NHibernate und aufgeben Linq Unterstützung
   • Verwendung linq2sql und zukünftige Unterstützung geben (nicht zu SQL Server auf DB gebunden bekommen zu erwähnen)
2. verlassen GUIDs und gehen mit einer anderen PK-Strategie
3. ein Verfahren entwickeln, um sequentielle GUIDs (Kämme?) Zu erzeugen, auf der Anwendungsschicht

Ich bin Neigung in Richtung Option 1 mit linq2sql (meinen Entwicklern wirklich wie linq2 [Sachen]) und 3. das vor allem, weil ich etwas unwissend von alternativen Schlüsselstrategien bin, der das Replikationsschema wir streben, während unterstützen auch halten Dinge Sane aus Sicht des Entwicklers.

Jede Einsicht oder Meinung wäre sehr dankbar.

Answer 1

Eine weitere Option (nicht verfügbar, wenn dies geschrieben wurde) ist auf EF 4, zu aktualisieren, die vom Server generierte GUIDs unterstützt.

Answer 2

Ich zweiten Craig Vorschlag - Option 4.

Sie können jederzeit die GUID Spalte, von der mittleren Ebene bevölkert verwenden, als Primärschlüssel (das ist ein logisches Konstrukt).

Um massive Index (also: Tabelle) zu vermeiden. Fragmentierung, verwenden Sie einen anderen Schlüssel (idealerweise eine INT IDENTITY-Spalte) als Gruppierungsschlüssel - das ist ein physisches Datenbank-Konstrukt, das aus dem Primärschlüssel getrennt werden kann

Standardmäßig ist der Primärschlüssel ist der Clustering-Schlüssel - aber das muss nicht so sein. In der Tat verbessern I Leistung und drastisch Fragmentierung verringert nur, dass auf einer Datenbank, indem ich „geerbt“ - fügen Sie eine Spalte INT IDENTITY und setzen Sie den Clustering-Schlüssel auf dieser kleinen, ständig wachsenden, nie verändernden INT - wirkt wie ein Zauber!

Marc

Answer 3

Hä? Ich denke, Ihre drei Optionen sind eine falsche Wahl. Betrachten Sie die Option 4:

  

4) Verwenden Sie das Entity Framework mit nicht-sequenziellen , Client generierte GUIDs.

Das EF kann nicht sehen, DB-Server generierten GUIDs für neue Zeilen durch den Rahmen eingefügt selbst , sicher, aber Sie brauchen nicht die GUIDs auf dem DB-Server zu erzeugen. Sie können sie auf dem Client generieren, wenn Sie Ihre Entitätsinstanzen erstellen. Der ganze Sinn eines GUID ist es spielt keine Rolle, wo Sie es erzeugen. Was von einer replizierten DB erzeugte GUIDs wird der EF sich einfach gut sehen.

Ihr clientseitige GUIDs wird nicht sequentiell sein (verwenden Guid.NewGuid ()), aber sie werden weltweit sein, die garantiert einzigartig.

Wir tun dies in der Schifffahrt, Produktions-Software mit der Replikation. Es hat Arbeit.

Answer 4

Warum nicht Identitätsspalte verwenden? Wenn Sie Mergereplikation tun Sie jeden Systemstart an einem separaten Saatgut und Arbeit in eine Richtung haben können (zum Beispiel Knoten a beginnen bei 1 und addiert 1, Knoten b beginnt bei 0 und subtrahiert eine) ...

Answer 5

Sie können gespeicherte Prozeduren verwenden, wenn Sie wirklich stecken NEWSEQUENTIALID auf () verwenden. Sie können die Ergebnisspalten aus dem Verfahren an der entsprechenden Eigenschaft binden und eingefügt, wenn der SQL-generierte GUID zurück in das Objekt eingespeist wird.

Leider müssen Sie SPs definieren für alle drei Operationen (Einfügen, Aktualisieren, Löschen), auch wenn die anderen Operationen richtig wäre vervollständigen die Standardeinstellungen verwenden. Sie müssen auch den SP-Code zu erhalten und sicherzustellen, dass es mit Ihrem EF-Modell synchronisiert ist, wie Sie Änderungen vornehmen, die diese Option wegen des zusätzlichen Aufwand unattraktiv machen können.

Es gibt ein Schritt-für-Schritt-Beispiel unter http://blogs.msdn.com/bags/archive/2009/03/12/entity-framework-modeling-action-stored-procedures.aspx die ziemlich gerade ist -forward.

Answer 6

verwendet newseqid mit Ihrem eigenen ORM (es ist nicht so schwer) mit Linq