PK jako ROWGUIDCOL lub użyj osobnej kolumny rowguid?

Odbywa się tutaj długa debata, więc chciałbym usłyszeć inne opinie.

Mam wiele tabel z klastrowanym unikalnym identyfikatorem PK. To, czy jest to dobry pomysł, jest tutaj poza zakresem (i to się wkrótce nie zmieni).

Teraz baza danych musi zostać opublikowana w trybie scalania, a DEV zalecają użycie oddzielnej kolumny rowguid zamiast oznaczania istniejącej PK jako ROWGUIDCOL.

Zasadniczo mówią, że aplikacja nigdy nie powinna przenosić do swojej domeny czegoś, co jest używane tylko przez replikację (jest to dla nich tylko „baza danych DBA”).

Z punktu widzenia wydajności nie widzę powodu, dla którego powinienem dodać nową kolumnę, aby zrobić coś, co mógłbym zrobić z istniejącą. Co więcej, skoro to tylko „rzeczy DBA”, dlaczego nie pozwolić DBA wybrać?

W pewnym sensie rozumiem punkt DEV, ale nadal się nie zgadzam.

Myśli?

EDYCJA: Chcę tylko dodać, że jestem w mniejszości w tej debacie, a DEV kwestionujący moje stanowisko to ludzie, których szanuję i którym ufam. Z tego powodu poprosiłem o opinie.
Mogłem też coś przeoczyć i mogłem źle zrozumieć ich punkt widzenia.

Zasadniczo mówią, że aplikacja nigdy nie powinna przenosić do swojej domeny czegoś, co jest używane tylko przez replikację (jest to dla nich tylko „baza danych DBA”).

Zgadzam się całkowicie. Ale ... klucz podstawowy nie jest używany tylko do replikacji (prawdopodobnie aplikacja używa go w jakiś sposób). Argument ten nie ma sensu w tym kontekście.

W każdym razie, o ile mi wiadomo, są tylko dwa sposoby, aby „DBA” przekroczyło granicę domeny:

1. Jeśli aplikacja używa zapytań, które odwołują się do ROWGUIDCOLkolumny w następujący sposób:

   DECLARE @a table (id uniqueidentifier ROWGUIDCOL);
   
   SELECT ROWGUIDCOL FROM @a;

   Zakładam, że żadna z twoich kolumn nie ma jeszcze tej właściwości, więc aplikacja by tego nie robiła. (Nawiasem mówiąc, ROWGUIDCOLjest to zupełnie odrębna koncepcja od replikacji. Tak się składa, że ​​replikacja scalająca używa jej.)

2. Kolumna klucza podstawowego nie będzie już możliwa do aktualizacji. Jeśli aplikacja to robi i nie zostaną wprowadzone zmiany w celu użycia innego algorytmu, nie ma innego wyboru, jak dodać nową kolumnę do tabeli, a zatem nie jest wymagana dyskusja.

Oprócz tych zachowań ROWGUIDCOLwłaściwość jest całkowicie przezroczysta. Możesz go dodać, a aplikacja nigdy się nie dowie. Jakikolwiek rodzaj replikacji danych scenariusza powinny być jak najbardziej przejrzyste dla aplikacji.

Zgadzam się. Tak długo, jak nie ma potrzeby zmiany wartości PK, lepiej byłoby użyć istniejącej unikalnej kolumny identyfikatora jako argumentu wiersza.

„Zasadniczo mówią, że aplikacja nigdy nie powinna przenosić do swojej domeny czegoś, co jest używane tylko przez replikację (jest to dla nich tylko„ baza danych DBA ”).”

Ale to nie jest używane tylko do replikacji. To także (i już) twój PK.