PK как ROWGUIDCOL или использовать отдельный столбец rowguid?

9

Здесь идут многословные дебаты, поэтому я хотел бы услышать другие мнения.

У меня много таблиц с уникальным идентификатором кластеризованного ПК. Является ли это хорошей идеей, здесь выходит за рамки (и она не изменится в ближайшее время).

Теперь база данных должна быть опубликована слиянием, и разработчики выступают за использование отдельного столбца rowguid вместо обозначения существующего PK как ROWGUIDCOL.

По сути, они говорят, что приложение никогда не должно вносить в свой домен что-то, что используется только для репликации (для них это всего лишь «материал DBA»).

С точки зрения производительности, я не вижу причин, почему я должен добавить новый столбец, чтобы сделать то, что я мог бы сделать с существующим. Более того, поскольку это всего лишь «материал для администраторов БД», почему бы не позволить администратору выбрать?

Я вроде понимаю точку зрения DEVs, но я все еще не согласен.

Мысли?

РЕДАКТИРОВАТЬ: Я просто хочу добавить, что я в меньшинстве в этой дискуссии, и DEV, подвергающие сомнению мою позицию, люди, которых я уважаю и которым доверяю. Это причина, почему я прибегаю к просьбе о мнениях.
Я мог бы также что-то упустить и мог неправильно понять их точку зрения.

sql-server database-design merge-replication

— spaghettidba
источник

Есть ли вероятность того, что значение PK может измениться в будущем?

— Роберт Л Дэвис

Нет, не совсем. Это суррогатный ключ, поэтому приложение мало что делает с этим столбцом. Он никогда не меняется и никогда не отображается пользователям.

— спагеттидба

Почему они хотят отдельный rowguidcol? И какую схему они вообще выберут, если смогут, для ПК и почему?

— JustinC

@spaghettidba Говоря о пересечении доменов, как часто вы говорите им, какие шаблоны проектирования они должны или не должны использовать в своем коде приложения? Может, им стоит придерживаться своего «домена»? ;-). Кроме того, добавление 16-байтового столбца во все таблицы было бы ужасно для производительности и не принесло бы никакой пользы.

— Соломон Руцки

7

По сути, они говорят, что приложение никогда не должно вносить в свой домен что-то, что используется только для репликации (для них это всего лишь «материал DBA»).

Я полностью согласен. Но ... первичный ключ используется не только для репликации (предположительно, приложение использует его каким-то образом). Аргумент не имеет смысла в этом контексте.

В любом случае, насколько мне известно, есть только 2 способа для этого "материала DBA" пересечь границу домена:

Если приложение использует запросы, которые ссылаются на ROWGUIDCOLстолбец следующим образом:
```
DECLARE @a table (id uniqueidentifier ROWGUIDCOL);

SELECT ROWGUIDCOL FROM @a;
```
Я предполагаю, что ни у одного из ваших столбцов нет этого свойства, поэтому приложение не будет этого делать. (Кстати, ROWGUIDCOLэто совершенно отдельная концепция от репликации. Просто так получилось, что репликация слиянием использует ее.)
Столбец первичного ключа больше не будет обновляемым. Если приложение делает это и изменения не будут вноситься, чтобы использовать другой алгоритм, нет другого выбора, кроме как добавить новый столбец в таблицу, и, следовательно, обсуждение не требуется.

Помимо этого поведения, ROWGUIDCOLсвойство является полностью прозрачным. Вы можете добавить его, и приложение никогда не узнает. Любой тип сценария репликации данных должен быть максимально прозрачным для приложений.

— Джон Сайгель
источник

Спасибо за ответы. Нет, приложение не выполняет 1. или 2. Для полноты картины некоторые таблицы уже имеют свойство ROWGUIDCOL в PK.

— спагеттидба

Хотя я согласен с тем, что репликация должна быть прозрачной для приложений, я также считаю, что базы данных, которые должны быть опубликованы, должны продумываться для репликации с нуля. Например, управление идентификацией в репликации слиянием - это полностью PITA: если вы знаете, что с самого начала вам придется объединять публикации, это одна вещь, от которой нужно держаться подальше.

— Спагеттидба

@ spaghettidba: Да, я полностью согласен с тем, что если репликация в картах, база данных определенно должна быть разработана для этого. Часто простое следование лучшим практикам поможет вам в этом; это уродливые, волосатые унаследованные базы данных, которые, как правило, имеют больше проблем с дизайном. Из моего опыта, репликация слиянием, в частности, является более сложной задачей, чем любой из других механизмов репликации.

— Джон Зигель

@spaghettidba and Jon: Только к вашему сведению, использование ROWGUIDCOLв этом контексте (то есть не в выражении CREATE TABLE/ ALTER TABLE) устарело по крайней мере с версии SQL Server 2008 R2 (поиск FeatureID 182) в пользу $ROWGUID.

— Соломон Руцки

6

Согласен. Поскольку нет необходимости изменять значение PK, лучше использовать существующий столбец uniqueidentifier в качестве rowguidcol.

— Роберт Л Дэвис
источник

5

«По сути, они говорят, что приложение никогда не должно вносить в свой домен что-то, что используется только для репликации (для них это всего лишь« материал DBA »)».

Но он не используется только для репликации. Это также (и уже) ваш ПК.

— Роберт Зеурункл
источник