Отрицательные первичные ключи

Есть ли какие-либо последствия с использованием отрицательных первичных ключей для таблиц (индекс идентичности -1, семестр идентичности -1 в SQL Server 2005)?

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

Ответ 1

Как и другие, база данных в порядке с этим.

Но это было бы проблемой для приложения .NET, которое использует DataSet + DataAdapter, поскольку они используют отрицательные ключи как временные для новых записей.

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

Ответ 2

Это отлично с точки зрения SQL Server. Реальный вопрос будет вашим приложением.

Ответ 3

Вы хотите просмотреть устаревший код и посмотреть, где разработчики отсортировали по первичному ключу как ленивый /sloppy способ сортировки по дате (поскольку идентификатор pk обычно сильно или отлично коррелирует со временем).

Ответ 4

Только проблема заключается в том, что вы не сможете добавить третий источник данных таким образом!

Ответ 5

Не проблема.

Это немного не ортодоксально, но кроме этого, отлично.

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

Ответ 6

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

Ответ 7

Это не проблема. Просто убедитесь, что столбец Identity имеет тип, который позволяет отрицательные числа.

Ответ 8

Другой вариант - префикс устаревших ключей с строкой типа "OLD_". Обойная проблема - ваше ключевое поле будет нечисловым.

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

Ответ 9

Я думаю, что наличие двух источников не является подходящей причиной для этого подхода, хотя технически разрешено. Он не масштабируется (+1 к Ларри Лустигу отвечает за это).

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