PK als ROWGUIDCOL oder eine separate Zeilenleiterspalte verwenden?

9

Hier findet eine langwierige Debatte statt, daher würde ich gerne andere Meinungen hören.

Ich habe viele Tabellen mit Uniqueidentifier Clustered PK. Ob dies eine gute Idee ist, ist hier nicht möglich (und es wird sich nicht so schnell ändern).

Jetzt muss die Datenbank zusammengeführt und veröffentlicht werden, und die DEVs befürworten die Verwendung einer separaten Zeilenleiterspalte, anstatt die vorhandene PK als ROWGUIDCOL zu markieren.

Grundsätzlich sagen sie, dass die Anwendung niemals etwas in ihre Domäne bringen sollte, das nur von der Replikation verwendet wird (es ist nur "DBA-Zeug" für sie).

Unter Leistungsgesichtspunkten sehe ich keinen Grund, warum ich eine neue Spalte hinzufügen sollte, um etwas zu tun, das ich mit einer vorhandenen tun könnte. Da es sich nur um "DBA-Zeug" handelt, lassen Sie den DBA wählen.

Ich verstehe den Punkt der DEVs irgendwie, aber ich bin immer noch anderer Meinung.

Gedanken?

EDIT: Ich möchte nur hinzufügen, dass ich in dieser Debatte in der Minderheit bin und die DEVs, die meine Position in Frage stellen, Menschen sind, die ich respektiere und denen ich vertraue. Dies ist der Grund, warum ich nach Meinungen gefragt habe.
Ich könnte auch etwas vermissen und ihren Punkt missverstanden haben.

sql-server database-design merge-replication

— spaghettidba
quelle

Gibt es eine Chance, dass sich ein PK-Wert in Zukunft ändern muss?

— Robert L Davis

Nein nicht wirklich. Es ist ein Ersatzschlüssel, daher macht die App mit dieser Spalte nicht wirklich viel. Es ändert sich nie und wird den Benutzern nie angezeigt.

— Spaghettidba

Warum wollen sie ein separates Rowguidcol? Und welches Schema würden sie im Allgemeinen für die PK wählen, wenn sie könnten, und warum?

— JustinC

@spaghettidba Apropos Domains überqueren, wie oft sagen Sie ihnen, welche Designmuster sie in ihrem App-Code verwenden sollen oder nicht? Vielleicht sollten sie sich an ihre "Domain" halten? ;-). Außerdem wäre das Hinzufügen einer 16-Byte-Spalte zu allen Tabellen für die Leistung schrecklich und bietet keinen Vorteil.

— Solomon Rutzky

7

Grundsätzlich sagen sie, dass die Anwendung niemals etwas in ihre Domäne bringen sollte, das nur von der Replikation verwendet wird (es ist nur "DBA-Zeug" für sie).

Ich stimme vollkommen zu. Aber ... der Primärschlüssel wird nicht nur für die Replikation verwendet (vermutlich wird er von der Anwendung auf irgendeine Weise verwendet). Das Argument macht in diesem Zusammenhang keinen Sinn.

Soweit mir bekannt ist, gibt es auf jeden Fall nur zwei Möglichkeiten, wie dieses "DBA-Zeug" die Domänengrenze überschreitet:

Wenn die Anwendung Abfragen verwendet, die ROWGUIDCOLwie folgt auf die Spalte verweisen :
```
DECLARE @a table (id uniqueidentifier ROWGUIDCOL);

SELECT ROWGUIDCOL FROM @a;
```
Ich gehe davon aus, dass noch keine Ihrer Spalten diese Eigenschaft hat, sodass die Anwendung dies nicht tun würde. (Übrigens ROWGUIDCOList das Konzept völlig unabhängig von der Replikation. Es kommt nur so vor, dass die Zusammenführungsreplikation es verwendet.)
Die Primärschlüsselspalte kann nicht mehr aktualisiert werden. Wenn die Anwendung dies tut und keine Änderungen vorgenommen werden, um einen anderen Algorithmus zu verwenden, bleibt keine andere Wahl , als der Tabelle eine neue Spalte hinzuzufügen, und daher ist keine Diskussion erforderlich.

Abgesehen von diesen Verhaltensweisen ist die ROWGUIDCOLEigenschaft vollständig transparent. Sie können es hinzufügen, und die Anwendung würde es nie erfahren. Jede Art von Datenreplikationsszenario sollte für Anwendungen so transparent wie möglich sein.

— Jon Seigel
quelle

Danke für die Antwort. Nein, die Anwendung führt weder 1. noch 2. Der Vollständigkeit halber sind einige Tabellen bereits mit der Eigenschaft ROWGUIDCOL in der PK dekoriert.

— Spaghettidba

Ich bin damit einverstanden, dass die Replikation für Anwendungen transparent sein sollte, glaube aber auch, dass Datenbanken, die veröffentlicht werden müssen , von Grund auf für die Replikation in Betracht gezogen werden müssen . Das Identitätsmanagement bei der Zusammenführungsreplikation ist beispielsweise vollständig PITA: Wenn Sie von Anfang an wissen, dass Sie die Veröffentlichung zusammenführen müssen, ist es eine Sache, sich davon fernzuhalten.

— Spaghettidba

@spaghettidba: Ja, ich stimme voll und ganz zu, dass die Datenbank definitiv dafür ausgelegt sein muss, wenn die Replikation in den Karten ist. Oft wird das einfache Befolgen von Best Practices den größten Teil des Weges dorthin zurücklegen. Es sind die hässlichen, haarigen Legacy-Datenbanken, die die meisten Designprobleme haben. Nach meiner Erfahrung ist die Zusammenführungsreplikation insbesondere schwieriger als alle anderen Replikationsmechanismen.

— Jon Seigel

@spaghettidba und Jon: Nur zu Ihrer Information, die Verwendung von ROWGUIDCOLin diesem Kontext (dh nicht in einer CREATE TABLE/ -Anweisung ALTER TABLE) ist seit mindestens SQL Server 2008 R2 (Suche nach FeatureID 182) zugunsten von veraltet $ROWGUID.

— Solomon Rutzky

6

Genau. Solange sich der PK-Wert nicht ändern muss, ist es besser, die vorhandene Spalte mit der eindeutigen Kennung als Zeilenleitfaden zu verwenden.

— Robert L Davis
quelle

5

"Grundsätzlich sagen sie, dass die Anwendung niemals etwas in ihre Domäne bringen sollte, das nur von der Replikation verwendet wird (es ist nur" DBA-Zeug "für sie)."

Es wird jedoch nicht nur für die Replikation verwendet. Es ist auch (und schon) deine PK.

— Robert Zeurunkl
quelle