PK come ROWGUIDCOL o utilizzare una colonna guida di riga separata?

9

C'è un dibattito prolisso in corso qui, quindi mi piacerebbe sentire altre opinioni.

Ho molte tabelle con PK clusteridentifiedidentifier. Se questa è una buona idea è fuori portata qui (e non cambierà presto).

Ora, il database deve essere unito e i DEV stanno sostenendo l'uso di una colonna guida a riga separata invece di contrassegnare il PK esistente come ROWGUIDCOL.

Fondamentalmente, dicono che l'applicazione non dovrebbe mai portare nel suo dominio qualcosa che viene utilizzato solo dalla replica (è solo "roba DBA" per loro).

Dal punto di vista delle prestazioni, non vedo alcun motivo per cui dovrei aggiungere una nuova colonna per fare qualcosa che potrei fare con una esistente. Inoltre, poiché è solo "roba DBA", perché non lasciare che la DBA scelga?

In un certo senso capisco il punto dei DEV, ma non sono ancora d'accordo.

Pensieri?

EDIT: Voglio solo aggiungere che sono in minoranza in questo dibattito e gli DEV che mettono in discussione la mia posizione sono persone che rispetto e di cui mi fido. Questo è il motivo per cui ho fatto ricorso alla richiesta di opinioni.
Potrei anche mancare qualcosa e avrei potuto fraintendere il loro punto.

sql-server database-design merge-replication

— spaghettidba
fonte

C'è qualche possibilità che un valore PK possa cambiare in futuro?

— Robert L Davis,

No, non proprio. È una chiave surrogata, quindi l'app non fa molto con quella colonna. Non cambia mai e non viene mai visualizzato dagli utenti.

— spaghettidba,

Perché vogliono un rowguidcol separato? E quale schema in generale sceglierebbero, se potessero, per il PK, e perché?

— Giustino,

@spaghettidba A proposito di attraversare domini, quanto spesso dici loro quali schemi di progettazione dovrebbero o non dovrebbero usare nel loro codice app? Forse dovrebbero attenersi al loro "dominio"? ;-). Inoltre, aggiungere una colonna di 16 byte a tutte le tabelle sarebbe orribile per le prestazioni e non offrirebbe alcun vantaggio.

— Solomon Rutzky,

7

Fondamentalmente, dicono che l'applicazione non dovrebbe mai portare nel suo dominio qualcosa che viene utilizzato solo dalla replica (è solo "roba DBA" per loro).

Sono completamente d'accordo. Ma ... la chiave primaria non viene utilizzata solo per la replica (presumibilmente l'applicazione la utilizza in qualche modo). L'argomento non ha senso in questo contesto.

In ogni caso, per quanto ne so, ci sono solo 2 modi in cui questa "roba DBA" può oltrepassare il confine del dominio:

Se l'applicazione utilizza query che fanno riferimento alla ROWGUIDCOLcolonna in questo modo:
```
DECLARE @a table (id uniqueidentifier ROWGUIDCOL);

SELECT ROWGUIDCOL FROM @a;
```
Suppongo che nessuna delle tue colonne abbia ancora questa proprietà, quindi l'applicazione non lo farebbe. (A proposito, ROWGUIDCOLè un concetto completamente separato dalla replica. Accade solo che la replica unita lo utilizza.)
La colonna chiave primaria non sarebbe più aggiornabile. Se l'applicazione lo sta facendo e non verranno apportate modifiche per utilizzare un altro algoritmo, non c'è altra scelta che aggiungere una nuova colonna alla tabella e quindi non è necessaria alcuna discussione.

A parte questi comportamenti, la ROWGUIDCOLproprietà è completamente trasparente. Puoi aggiungerlo e l'applicazione non lo saprebbe mai. Qualsiasi tipo di scenario di replica dei dati dovrebbe essere il più trasparente possibile per le applicazioni.

— Jon Seigel
fonte

Grazie per aver risposto. No, l'applicazione non sta eseguendo 1. né 2. Per completezza, alcuni tavoli sono già decorati con la proprietà ROWGUIDCOL nel PK.

— spaghettidba,

Mentre sono d'accordo sul fatto che la replica dovrebbe essere trasparente per le applicazioni, credo anche che i database che devono essere pubblicati debbano essere pensati per la replica da zero. La gestione delle identità nella replica di tipo merge è totalmente PITA, per esempio: se sai dall'inizio dovrai unire la pubblicazione, è una cosa a cui stare lontano.

— spaghettidba,

@spaghettidba: Sì, sono completamente d'accordo sul fatto che se la replica è nelle schede, il database deve essere sicuramente progettato per questo. Spesso semplicemente seguire le migliori pratiche otterrà la maggior parte del percorso; sono i database legacy brutti e pelosi che tendono ad avere i maggiori problemi di progettazione. Dalla mia esperienza, unire la replica in particolare è più impegnativo di qualsiasi altro meccanismo di replica.

— Jon Seigel,

@spaghettidba e Jon: Solo FYI, l'uso di ROWGUIDCOLin quel contesto (cioè non in un'istruzione CREATE TABLE/ ALTER TABLE) è stato deprecato almeno da SQL Server 2008 R2 (ricerca di FeatureID 182) a favore di $ROWGUID.

— Solomon Rutzky,

6

Sono d'accordo. Finché non è necessario che il valore PK sia in grado di cambiare, sarebbe meglio usare la colonna uniqueidentifier esistente come rowguidcol.

— Robert L Davis
fonte

5

"Fondamentalmente, dicono che l'applicazione non dovrebbe mai portare nel suo dominio qualcosa che viene utilizzato solo dalla replica (è solo" roba DBA "per loro)."

Ma non è usato solo per la replica. È anche (e già) il tuo PK.

— Robert Zeurunkl
fonte