Это хорошая идея использовать rowguid в качестве уникального ключа в дизайне базы данных?

Question

SQL Server предоставляет тип [rowguid]. Мне нравится использовать это как уникальный первичный ключ, чтобы идентифицировать строку для обновления. Преимущество проявляется в том, что если вы выгрузите таблицу и перезагрузите ее, не возникнет путаницы со столбцами SerialNo (identity).

В особом случае распределенных баз данных, таких как автономные копии на ноутбуках или что-то в этом роде, больше ничего не работает.

Что ты думаешь? Слишком много накладных расходов?

Answer 1

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

НО: в SQL Server первичным ключом по умолчанию является также ключ кластеризации в вашей таблице, и использование ROWGUID в качестве ключа кластеризации действительно очень плохо идея. См. Превосходные GUID Кимберли Триппа в качестве ПЕРВИЧНОГО и / или статью о ключе кластеризации для более подробной информации, почему бы не использовать GUID для кластеризации.

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

Кроме того, поскольку ключ кластеризации добавляется в каждое поле каждого некластеризованного индекса в вашей таблице, вы тратите много места - как на диске, так и в оперативной памяти сервера - при использовании 16-байтовый GUID против 4-байтового INT.

Итак: да, в качестве первичного ключа у ROWGUID есть свои достоинства - но если вы его используете, определенно избегайте использования этого столбца в качестве ключа кластеризации в таблице! Используйте INT IDENTITY () или что-то подобное для этого.

Для ключа кластеризации, в идеале, вы должны искать четыре функции:

• стабильный (никогда не меняется)
• уникальный
• как можно меньше
• постоянно растет

INT IDENTITY () идеально подходит для этой цели. И да - ключ кластеризации должен быть уникальным, поскольку он используется для физического нахождения строки в таблице - если вы выберете столбец, который не может быть гарантированно уникальным, SQL Server фактически добавит четырехбайтовый уникализатор к вашему ключу кластеризации - опять же, не то, что вы хотите иметь ...

Извлечение Дебаты о кластеризованном индексе продолжаются - еще одна замечательная и проницательная статья Ким Трипп («Королева индексации SQL Server»), в которой она очень хорошо и подробно объясняет все эти требования.

1038 * MARC *

Answer 2

Проблема с rowguid состоит в том, что, если вы используете его для своего кластерного индекса, вы в конечном итоге будете постоянно пересчитывать страницы таблицы для вставок записей. Последовательный guid (NEWSEQUENTIALID ()) часто работает лучше.

Answer 3

Вопреки принятому ответу тип данных uniqueidentifier в SQL Server действительно является хорошим кандидатом на первичный ключ кластеризации; до тех пор, пока вы сохраняете это последовательно.

Это легко сделать, используя (newsequentialid ()) в качестве значения по умолчанию для столбца.

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

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

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

Хранение данных на сервере недешево, но я бы предпочел иметь базу данных, которая использует немного больше места, чем база данных, которая останавливается, когда ваши автоматически назначенные диапазоны идентичности перекрываются.

Answer 4

Наше автономное приложение используется в филиалах, и у нас есть центральная база данных в нашем главном офисе. Для синхронизации базы данных с центральной базой данных мы использовали столбец rowguid во всех таблицах. Может быть, есть лучшие решения, но нам легче. За последние 3 года мы не сталкивались с какой-либо серьезной проблемой до настоящего времени.