Столбцы идентификации или UDF, которые явно генерируют уникальный идентификатор?

Question

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

• Я спорю о столбце идентификации.
• Мой партнер выступает за создание ценностей вручную, он утверждает
  • Поместив UDF на другой таблицу, где мы можем иметь UDF
    • Заблокируйте ресурс
    • увеличить таблицу идентификации с одним полевым ID_Value по 1
    • Используйте это как глобальный уникальный идентификатор
  • Или попросить стол сделать id+1 При вставке
  • Что проще перемещать данные между серверами и/или средами, не имеющими ограничения идентификации; Переезд из одного БД, где есть данные в другой аналогичный БД с скажем, постановкой или фиктивными данными. Для тестирования в непроизводстве мы можем захотеть вывести все записи со вчерашнего дня до постановки тестирования.

Какая реализация имеет больше смысла?

Answer 1

Ваш коллега идиот.

Решение не будет масштабируемым, UDF не одновременно (Та же причина, что и эта) И как вы справляетесь с многорядными вставками: это потребует вызова UDF на строку

И переход на другие RDBMS не часто случается в реальной жизни ... вы также можете не использовать SQL Server сейчас и использовать последовательности на Oracle и надеяться, что вы не перейдете.

Редактировать:

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

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

Или используем процессы: мы обновляем нашу тестовую систему каждую ночь от производства, что полностью избегает проблемы. (И гарантирует, что наше резервное копирование также может быть восстановлено)

Answer 2

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

Идентичность существует по какой -то причине, используйте ее.

Когда выйдет SQL Denali, он будет поддерживать последовательности, которые будут более эффективными, чем идентичность, но вы не можете создать что -то более эффективное самостоятельно.

Что касается перемещения записей из одной среды в другую, либо включите Identity_insert при выполнении вставки, либо на флажок в SSIS.

Answer 3

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

Если вы хотите, чтобы у каждого ряда была глобально уникальная идентичность, вы можете использовать UUID, но я бы не сделал этого, если вы не уверены, что глобальная уникальность необходима - обычно это не так. Использование UUIDS в качестве идентификаторов уменьшит производительность, увеличит требования к дисковому пространству и усложняет отладку - из -за длины трудно запомнить UUID, рассказать кому -то по телефону или записать на бумаге без ошибок.

Answer 4

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

Вы всегда можете создать «супер таблицу», которая использует идентичность в качестве PK и иметь столбец типа, и любая другая информация. Когда вам нужен новый идентификатор (при условии, что вы имеете в виду уникальные идентификаторы в разных таблицах) просто вставьте в эту таблицу и возьмите SCOPE_IDENTITY() и затем вставьте в нужную таблицу.

В основном вы создаете таблицу: Мастер С идентификацией PK, когда вам нужно вставить строку в свою таблицу, INSERT INTO MasterIDs и получить идентичность, сгенерированную этой строкой, используя SCOPE_IDENTITY() а затем вставить в Таблица 1 Используя это значение в качестве PK.

Таблица 1 Будет невидительность int pk. Вы сделаете тот же процесс для вставки в таблицу2 и т. Д. Пусть SQL Server управляет значениями идентификации в Мастер Таблица, которую вы можете использовать в других ваших таблицах. Мастер Может содержать другие таблицы, такие как тип (чтобы вы могли знать, какая таблица, таблица 1 или таблица 2 и т. Д. Используют это значение идентификации.

Answer 5

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

Answer 6

Личность была сделана, чтобы соответствовать вашему сценарию. У вас есть такие инструменты, как репликация для обмена данными сервера/среды, которые удерживают все это вместе.

Answer 7

Я только что закончил работу, где я заменил SQL Server identity колонна с нормальным int Поле и контролируемое распределение идентификаторов.

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

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

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

Answer 8

Я использую идентичность в течение многих лет и серьезно рассмотрю замену номера идентификации уникальным идентификатором. Это кошмар, когда вам нужно изменить тип данных, если кто -то разработал его как компактный DB и кошмар, если вам нужно добавить личность в столбец, также вы не можете обновить столбец идентификации. Представьте, что вы поместите INT, и ваша база данных выходит за рамки 2 миллиардов записей, снова кошмар, чтобы измениться (рассмотрите FKS)! Изменение чего -либо с помощью личности - это кошмар, и он не дружелюбен, если вы не положите Bigint! Уникальный идентификатор против идентичности = удобство и надежность, возможно, заметное улучшение производительности (не делал эталона).

Обновление: после того, как я увидел это Я определенно склоняюсь к уникальному идентификатору. Это не показывает реальной пользы от идентичности Bigint и куча преимуществ для уникального идентификатора! Различные версии SQL Server могут иметь другой результат. Существует просто красота в наличии уникального идентификатора во всех базах данных и системах (надежность)! Переместите, копируйте, преобразуйте данные, как вам нравится!https://www.mssqltips.com/sqlservertip/5105/sql-server-performance-comparison-int-versus-guid/