Является ли использование MS SQL Identity хорошей практикой? - PullRequest
5 голосов
/ 30 мая 2009

Является ли использование MS SQL Identity хорошей практикой в ​​корпоративных приложениях? Разве это не затрудняет создание бизнес-логики и перенос базы данных из одной в другую?

Ответы [ 5 ]

14 голосов
/ 30 мая 2009

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

Первоначально основная причина не использовать столбцы идентификаторов AFAIK была вызвана распределенными схемами из нескольких баз данных (отключенными) с использованием репликации и / или различных компонентов промежуточного программного обеспечения для перемещения данных. Просто не было распределенного механизма синхронизации и, следовательно, не было надежных средств предотвращения столкновений. Это значительно изменилось, так как SQL Server поддерживает распространение идентификаторов. Однако их использование может не соответствовать более сложным схемам репликации, управляемой приложением.

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

Я постоянно сталкиваюсь с проблемами, связанными с объединением клиентских баз, и все стороны все еще хотят сохранить свои старые номера счетов. Это иногда заставляет меня усомниться в моей зависимости от полей идентичности:)

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

10 голосов
/ 30 мая 2009

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

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

  1. БД: Использовать столбец идентификации или нет?
  2. http://www.codeproject.com/KB/database/AgileWareNewGuid.aspx?display=Print
  3. http://www.sqlmag.com/Article/ArticleID/48165/sql_server_48165.html
5 голосов
/ 30 мая 2009

Вопрос всегда:

Каковы шансы, что вы реально собираетесь перейти с одной базы данных на другую? Если вы создаете приложение с несколькими базами данных, это уже другая история, но большинство приложений никогда не переносятся на новый средний уровень базы данных, особенно когда они начинаются с чего-то более надежного, чем SQL Server.

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

Свойство IDENTITY: многозначная конструкция в SQL Server

5 голосов
/ 30 мая 2009

Да.

Как правило, они работают как задумано, и вы можете использовать команду DBCC CHECKIDENT для манипулирования ими и работы с ними.

Самая распространенная идея идентификации - предоставить упорядоченный список номеров, на которых можно основать первичный ключ.

Редактировать: Я был не прав относительно коэффициента заполнения, я не учел, что все вставки будут происходить с одной стороны B-дерева.

Кроме того, в своем исправленном вопросе вы спрашивали о миграции с одной БД на другую:

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

См .: Когда вы действительно вынуждены использовать UUID как часть проекта? для обсуждения того, когда использовать UUID в базе данных.

1 голос
/ 01 июня 2009

Хорошая статья о тождествах, http://www.simple -talk.com / sql / t-sql-программирования / identity-колонки /

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

http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/02/24/writing-ansi-standard-sql-is-not-practical.aspx

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...