Предотвращение дублирования ключей между несколькими базами данных - PullRequest
Новая
       10

Предотвращение дублирования ключей между несколькими базами данных

1 голос
/ 01 мая 2009

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

Возможные решения, которые я придумала:

  1. Используйте тип данных, который поддерживает действительно большие числа, и выделяйте диапазон для каждого, надеясь, что они никогда не переполнятся.
  2. Используйте отрицательные значения для одной базы данных и положительные значения для другой.
  3. Добавление дополнительного столбца, который идентифицирует базу данных и использует комбинацию этого и текущего идентификатора в качестве ключа.
  4. Cry.

Что еще я мог сделать? Существуют ли более элегантные решения для совместной работы двух баз данных? Я полагаю, что две базы данных будут на одном сервере, если это имеет значение.

Ответы [ 7 ]

6 голосов
/ 01 мая 2009

GUID или глобально уникальные идентификаторы могут быть удобными первичными ключами в этом случае. Я считаю, что Sybase поддерживает их.

Редактировать: Хотя, если вся ваша база данных уже основана на целочисленных первичных ключах, переключение на GUID может оказаться не очень практичным - в этом случае просто разделите целочисленное пространство между базами данных, как предложили GWLlosa и другие.

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

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

Я бы рекомендовал против любых других уловок, хотя бы потому, что все они требуют изменений в «устаревшем» приложении, что является риском, который я не вижу необходимости принимать.

3 голосов
/ 01 мая 2009

В вашем случае я бы рассмотрел использование uniqueidentifier (GUID) в качестве типа данных. Они считаются уникальными при их создании с помощью системной функции newid(). 

CREATE TABLE customer (
   cust_key UNIQUEIDENTIFIER NOT NULL
            DEFAULT NEWID( ),
   rep_key VARCHAR(5),
   PRIMARY KEY(cust_key))
2 голосов
/ 01 мая 2009

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

2 голосов
/ 01 мая 2009

GUID предназначены для этой ситуации.

2 голосов
/ 01 мая 2009

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

Я делал это в прошлом, и объем записей был достаточно низким, поэтому я начал свою новую базу данных с 200 000 в качестве начального номера записи. затем, когда пришло время, я просто перенес все старые записи в новую систему.

Отлично сработало!

1 голос
/ 01 мая 2009

Используйте тип данных UNIQUEIDENTIFIER. Я знаю, что он работает в MS SQL Server, и, насколько я вижу из Google, Sybase поддерживает его.

http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbrfen9/00000099.htm

...