PK як ROWGUIDCOL або використовувати окремий стовпець rowguid?

9

Тут триває тривала дискусія, тому я хотів би почути інші думки.

У мене багато таблиць з унікальним ідентифікатором PK. Невже це гарна ідея, тут виходить за межі сфери (і вона не скоро зміниться).

Тепер база даних повинна бути опублікована, і DEV виступають за використання окремого стовпчика рядкових рядів, а не для позначення існуючого ПК як ROWGUIDCOL.

В основному вони кажуть, що програма ніколи не повинна вносити у свій домен те, що використовується лише реплікацією (для них це лише "DBA речі").

З точки зору ефективності, я не бачу жодної причини, чому я повинен додавати новий стовпець, щоб зробити щось, що я міг би зробити з існуючим. Більше того, оскільки це лише "речі DBA", чому б не дозволити DBA вибирати?

Я якось розумію точку DEV, але я все ще не згоден.

Думки?

EDIT: Я просто хочу додати, що я в меншості в цій дискусії, і девелопери ставлять під сумнів свою позицію - це люди, яких я поважаю і довіряю. Це причина, чому я вдався просити думки.
Я також можу щось пропустити і міг неправильно зрозуміти їхню точку зору.

sql-server database-design merge-replication

— спагеттідба
джерело

Чи є ймовірність, що значення ПК в майбутньому може знадобитися змінити?

— Роберт Л Девіс

Ні, не дуже. Це сурогатний ключ, тому додаток насправді не робить багато з цим стовпцем. Він ніколи не змінюється і ніколи не відображається користувачам.

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

Чому вони хочуть окремий рядок? І яку схему взагалі обрали б, якщо могли, для ПК та чому?

— JustinC

@spaghettidba Якщо говорити про перехрещення доменів, як часто ви кажете їм, які шаблони дизайну вони повинні чи не повинні використовувати у коді додатка? Може, вони повинні дотримуватися свого "домену"? ;-). Крім того, додавання 16-байтового стовпчика до всіх таблиць буде жахливим для продуктивності та не принесе користі.

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

7

В основному вони кажуть, що програма ніколи не повинна вносити у свій домен те, що використовується лише реплікацією (для них це лише "DBA речі").

Я згоден повністю. Але ... первинний ключ використовується не тільки для реплікації (імовірно, програма використовує його якимось чином). Аргумент не має сенсу в цьому контексті.

У будь-якому випадку, наскільки мені відомо, існують лише два способи для цього "DBA речі" перейти межу домену:

Якщо програма використовує запити, що посилаються на такий ROWGUIDCOLстовпець:
```
DECLARE @a table (id uniqueidentifier ROWGUIDCOL);

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

За винятком поведінки, ROWGUIDCOLвластивість є повністю прозорою. Ви можете додати його, і додаток ніколи не дізнається. Будь-який тип сценарію реплікації даних повинен бути максимально прозорим для додатків.

— Джон Сейгель
джерело

Дякую за відповідь. Ні, додаток не робить ні 1., ні 2. Для повноти деякі таблиці вже прикрашені властивістю ROWGUIDCOL в ПК.

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

Хоча я погоджуюся, що реплікація повинна бути прозорою для додатків, я також вважаю, що бази даних, які мають бути опубліковані, повинні розглядатися для реплікації з самого початку. Наприклад, управління ідентичністю при тиражуванні злиття є повністю PITA, наприклад: якщо ви знаєте з самого початку, вам доведеться об'єднати публікацію, це одне, що слід оминати.

— spaghettidba

@spaghettidba: Так, я повністю погоджуюся, що якщо реплікація знаходиться на картках, база даних безумовно повинна бути розроблена для цього. Часто просто дотримання найкращих практик пройде більшу частину шляху; це негарні, волохаті бази даних, які мають найчастіше проблеми з дизайном. З мого досвіду, зокрема, реплікація злиття є складнішою, ніж будь-який з інших механізмів реплікації.

— Джон Сейгель

@spaghettidba та Jon: Просто FYI, використання ROWGUIDCOLв цьому контексті (тобто не в CREATE TABLE/ ALTER TABLEзаяві) було вичерпано, оскільки принаймні SQL Server 2008 R2 (пошук FeatureID 182) на користь $ROWGUID.

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

6

Я згоден. Поки немає необхідності, щоб значення PK могло змінюватися, тоді було б краще використовувати наявний стовпець унікального ідентифікатора як rowguidcol.

— Роберт Л Девіс
джерело

5

"В основному, вони кажуть, що програма ніколи не повинна вносити у свій домен те, що використовується лише реплікацією (це лише" DBA речі ")."

Але він не використовується лише для реплікації. Це також (і вже) ваш ПК.

— Роберт Зюрункл
джерело