Есть ли какие-либо последствия с использованием отрицательных первичных ключей для таблиц (индекс идентичности -1, семестр идентичности -1 в SQL Server 2005)?
Причиной этого является создание новой базы данных для замены существующей. Между двумя базами данных есть похожие таблицы, и мы хотим, чтобы "источник" информации был прозрачным для наших приложений. Подход заключается в создании представлений, которые объединяют таблицы из обеих баз данных. Отрицательные PK обеспечивают идентичность не перекрываются.
Как и другие, база данных в порядке с этим.
Но это было бы проблемой для приложения .NET, которое использует DataSet + DataAdapter, поскольку они используют отрицательные ключи как временные для новых записей.
Другие уровни доступа к данным могут использовать аналогичные трюки.
Это отлично с точки зрения SQL Server. Реальный вопрос будет вашим приложением.
Вы хотите просмотреть устаревший код и посмотреть, где разработчики отсортировали по первичному ключу как ленивый /sloppy способ сортировки по дате (поскольку идентификатор pk обычно сильно или отлично коррелирует со временем).
Только проблема заключается в том, что вы не сможете добавить третий источник данных таким образом!
Не проблема.
Это немного не ортодоксально, но кроме этого, отлично.
По умолчанию, предлагаемое SQL Server, это - по умолчанию и может быть изменено в соответствии с потребностями. Похоже, вы получили хороший компромисс.
Если отрицательные числа оказываются сломаны, используйте четные числа для одного и нечетного числа для другого.
Это не проблема. Просто убедитесь, что столбец Identity имеет тип, который позволяет отрицательные числа.
Другой вариант - префикс устаревших ключей с строкой типа "OLD_". Обойная проблема - ваше ключевое поле будет нечисловым.
Если вы должны иметь числовые клавиши, вы можете ввести столбец индикатора "устаревший", а первичный ключ будет представлять собой комбинацию числового идентификатора и устаревшего индикатора (надеюсь, эта комбинация должна быть уникальной).
Я думаю, что наличие двух источников не является подходящей причиной для этого подхода, хотя технически разрешено. Он не масштабируется (+1 к Ларри Лустигу отвечает за это).
Я бы просто создал представление или хранимую процедуру, которая объединяет оба данных, путем преобразования идентификаторов по мере необходимости и будет иметь приложение для использования вместо прямых табличных чтений и объединений. Это можно было бы масштабировать, изменив представление /SP позже, чтобы добавить еще один источник.