PK jako ROWGUIDCOL lub użyj osobnej kolumny rowguid?

9

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.

sql-server database-design merge-replication

— spaghettidba
źródło

Czy jest jakaś szansa, że wartość PK może wymagać zmiany w przyszłości?

— Robert L. Davis,

Nie, nie bardzo. Jest to klucz zastępczy, więc aplikacja tak naprawdę niewiele robi z tą kolumną. Nigdy się nie zmienia i nigdy nie jest wyświetlany użytkownikom.

— spaghettidba

Dlaczego chcą osobnego rowguidcol? A jaki system w ogóle wybraliby, gdyby mogli, dla PK i dlaczego?

— JustinC

@spaghettidba Mówiąc o przekraczaniu domen, jak często mówisz im, jakie wzorce projektowe powinni lub nie powinni stosować w kodzie aplikacji? Może powinni trzymać się swojej „domeny”? ;-). Poza tym dodanie 16-bajtowej kolumny do wszystkich tabel byłoby straszne z punktu widzenia wydajności i nie przyniosłoby żadnych korzyści.

— Solomon Rutzky

7

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:

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.)
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.

— Jon Seigel
źródło

Dzięki za odpowiedź. Nie, aplikacja nie wykonuje 1. ani 2. Ze względu na kompletność niektóre tabele są już ozdobione właściwością ROWGUIDCOL w PK.

— spaghettidba

Chociaż zgadzam się, że replikacja powinna być przezroczysta dla aplikacji, uważam również, że bazy danych, które należy opublikować, muszą być przemyślane pod kątem replikacji od podstaw. Zarządzanie tożsamością w replikacji scalania to całkowicie PITA, na przykład: jeśli wiesz, że od samego początku będziesz musiał scalić publikowanie, unikaj jednego.

— spaghettidba

@spaghettidba: Tak, zgadzam się całkowicie, że jeśli replikacja jest w kartach, baza danych zdecydowanie musi być do tego zaprojektowana. Często po prostu przestrzeganie najlepszych praktyk da sobie radę. to brzydkie, włochate, starsze bazy danych, które mają najwięcej problemów projektowych. Z mojego doświadczenia wynika, że w szczególności scalanie replikacji jest trudniejsze niż jakikolwiek inny mechanizm replikacji.

— Jon Seigel

@spaghettidba and Jon: Po prostu FYI, użycie ROWGUIDCOLw tym kontekście (tj. nie w instrukcji CREATE TABLE/ ALTER TABLE) jest przestarzałe od co najmniej SQL Server 2008 R2 (poszukiwanie FeatureID 182) na korzyść $ROWGUID.

— Solomon Rutzky

6

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.

— Robert L. Davis
źródło

5

„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.

— Robert Zeurunkl
źródło