Копирование отношений 1-к-1 с полями идентичности в SQL - PullRequest
2 голосов
/ 09 марта 2011

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

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

Как мне скопировать записи из одного набора таблиц в другой набор?

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

  • Опция 1: Временно отключить личность в пункте назначения родительская таблица. Копировать записи из родительская таблица, затем дочерняя таблица, сохраняя те же значения для основной ключ. Скрестите пальцы, которые нет конфликтов (значение первичный ключ исходной таблицы уже существует в таблице назначения).

  • Вариант 2: Временно добавить столбец в родительская таблица назначения для хранения «старый» (исходный) первичный ключ. копия записи из родительской таблицы, позволяя базе данных назначать новый первичный ключ, но сохраняя старый первичный ключ во временном столбце. Копировать записи из дочерней таблицы, присоединение исходной дочерней таблицы к родительская таблица назначения через старый первичный ключ, используя соединение с вставить запись в дочерний стол назначения с новым основной ключ. Бросьте временный столбец из родительского пункта назначения таблица.

  • Вариант 3: Копировать последовательно запись за записью, сначала от родителя родителю, потом ребенку, используя БД предоставил "личность последнего вставлена ​​запись "функции для обеспечения что ссылка поддерживается.

Из этих вариантов, я думаю, вариант 2 - мое предпочтение. Кто-нибудь предпочитает один из двух других вариантов, и если да, то почему? У кого-нибудь есть другое решение, которое "лучше"?

Ответы [ 3 ]

1 голос
/ 09 марта 2011

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

Если у вас нет этого уникального ключа, то, учитывая вашу ситуацию, я согласен, что вашим лучшим решением будет вариант № 2.

0 голосов
/ 19 марта 2011

Мои деньги на Варианте 1 (см. SET IDENTITY INSERT, http://msdn.microsoft.com/en-us/library/ms188059.aspx).

Но: почему вы их копируете?

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

Но чтобы ответить на ваш вопрос, определенно используйте Вариант 1.

0 голосов
/ 09 марта 2011

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

  1. список таблиц, которые ссылаются на данные из родительской и дочерней таблиц (оба набора таблиц)
  2. Существуют ли какие-либо хранимые процедуры / триггеры, которые используют данные в этих таблицах?
  3. Как заполняется эта таблица? Существует ли приложение / фид данных, который вставляет данные в эту таблицу?
  4. Как данные в этой таблице удаляются?
  5. Какова цель первичного ключа помимо обеспечения уникальности в таблице? Для этого вам нужно понять, как данные в таблице используются приложением.

На основе ответов вы сможете выбрать правильное решение, которое будет соответствовать требованиям приложения.

...