Действительно ли это - хорошая идея использовать rowguid в качестве уникального ключа в проектировании баз данных?
Необходимо сделать ночные сборки, чтобы гарантировать, что кодовая база остается здоровой.
побочный эффект А выполнения ночных сборок состоит в том, что оно вынуждает команду создать и поддержать полностью автоматизированный сценарий сборки. Это помогает гарантировать, что Ваш процесс сборки документируется и повторяем.
Автоматизированные сборки способны находить следующие проблемы:
- Кто-то зарегистрировался в чем-то, что повреждает материал.
- Кто-то забыл регистрироваться в необходимом файле или изменении.
- Ваши сценарии сборки больше не работают.
- Ваша машина сборки повреждается.
Выполнение это ночью гарантирует, чтобы Вы поймали такие проблемы в течение 24 часов после того, когда они происходят. Это предпочтительно для нахождения всех проблем за 24 часа до того, как Вы, как предполагается, поставляете программное обеспечение.
необходимо было также, конечно, автоматизировать модульные тесты, которые выполняются для каждой ночной сборки.
3 ответа
Как первичный ключ в логическом смысле (однозначно идентифицирующий ваши строки) - да, безусловно, имеет смысл.
НО: в SQL Server , первичный ключ по умолчанию также является ключом кластеризации вашей таблицы, и использование ROWGUID в качестве ключа кластеризации - действительно плохая идея. См. Превосходные GUID Кимберли Триппа в качестве ПЕРВИЧНЫХ и / или статью о ключах кластеризации , чтобы подробно узнать, почему не использовать GUID для кластеризации.
Поскольку GUID по определению является случайным, у вас будет ужасная фрагментация индекса и, следовательно, действительно очень плохая производительность операторов вставки, обновления, удаления и выбора.
Кроме того, поскольку ключ кластеризации добавляется в каждое поле каждого некластеризованного индекса в вашей таблице, вы re тратит много места - как на диске, так и в оперативной памяти сервера - при использовании 16-байтового GUID вместо 4-байтового INT.
Итак: да, в качестве первичного ключа ROWGUID имеет свои достоинства - но если вы его используете, определенно избегайте использования этого столбца в качестве ключа кластеризации в таблице! Используйте для этого INT IDENTITY () или что-то подобное.
Для ключа кластеризации в идеале вы должны искать четыре свойства:
- стабильный (никогда не меняется)
- уникальный
- как можно меньше
- постоянно увеличивающийся
INT IDENTITY () идеально подходит для этой потребности. И да - ключ кластеризации должен быть уникальным, поскольку он используется для физического нахождения строки в таблице - если вы выберете столбец, уникальность которого не может быть гарантирована, SQL Server фактически добавит четырехбайтовый уникальный определитель к вашему ключу кластеризации. - опять же, не то, чего вы хотите ....
Наше автономное приложение используется в филиалах, и у нас есть центральная база данных в нашем главном офисе. Чтобы синхронизировать базу данных с центральной базой данных, мы использовали столбец rowguid во всех таблицах. Может быть, есть решения получше, но нам так проще. На сегодняшний день мы не сталкивались ни с какими серьезными проблемами за последние 3 года.
Проблема с rowguid в том, что если вы используете его для кластерного индекса, вы в конечном итоге постоянно пересчитываете страницы таблицы для вставки записей. Последовательный гид (NEWSEQUENTIALID ()) часто работает лучше.