Предложение по производительности SQL Server - PullRequest
2 голосов
/ 09 января 2012

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

В таблицах используется типичный первичный ключ, данныевведите int и приращение идентификатора.При настройке репликации слиянием я должен добавить rowguid во все таблицы с помощью функции newsequentialid () для значения по умолчанию.Я заметил, что у rowguid есть indexable, и мне было интересно, нужен ли мне первичный ключ больше?

Можно ли иметь 2 индекса: первичный ключ int и rowguid?Каков наилучший макет для таблицы репликации слиянием?Сохраняю ли я int id для простой ссылки на строки и просто удаляю индекс, но сохраняю первичный ключ?Не уверен, какой маршрут выбрать, спасибо.

Ответы [ 2 ]

1 голос
/ 09 января 2012

Помните, что если вы удалите столбец int id и замените его на GUID, возможно, вам придется переделать значительную часть ваших данных и ваших запросов.И действительно ли вы хотите выполнять запросы вроде:

select * from orders where customer_id = '2053995D-4EFE-41C0-8A04-00009890024A'  

Помните, что ваши идентификаторы открыты для каких-либо пользователей (часто в случае клиента, потому что таблица клиентов часто не имеет естественного ключа, поскольку имена не уникальны), они найдут гидом пугающим для проведения исследований.

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

0 голосов
/ 09 января 2012

Единственным недостатком замены целочисленного первичного ключа на guid (который я знаю) является то, что GUID больше, поэтому btree (используемое индексное пространство) будет больше, и если у вас есть внешние ключи к этой таблице (которые вытакже необходимо изменить) гораздо больше места может быть использовано в (потенциально) многих таблицах.

...