Oracle вручную добавляет ограничение FK

Хорошо, поскольку клиент хочет автоматизировать определенный процесс, который включает в себя создание новой ключевой структуры в базе данных LIVE, мне нужно создать отношения между таблицами и столбцами. Теперь я нашел таблицы ALL_CONS_COLS и USER_CONSTRAINTS для хранения информации об ограничениях. Если бы я вручную создавал ограничения, вставляя их в эти таблицы, я мог бы воссоздать исходные ограничения. Мой вопрос: есть ли еще таблицы, на которые я должен обратить внимание? У вас есть альтернативные предложения, так как это звучит ОЧЕНЬ грязно и подвержено ошибкам с самого начала.

Текущий метод работы:

  • Создайте новый столбец в каждой таблице для ПК;

  • Создайте руководство для этого ПК;

  • Создайте новый столбец в каждой таблице для FK;

  • Получить guid, связанный с
    FK;

....... готово......

  • Добавить новое ограничение на основе старого
    ;

  • Удалить старое ограничение;

  • Переименовать новые столбцы;

Это довольно хитро, и я бы предпочел изменить свой метод, любые идеи будут полезны.

Другими словами, клиент хочет изменить структуру ключей с int на guid в действующей базе данных. Как лучше всего подойти к этому


constraints key oracle guid manual
person Oxymoron    schedule 06.05.2010    source источник

Ответы (1)


arrow_upward
4
arrow_downward

Прежде всего, вы не создаете/модифицируете/удаляете ограничения, возясь со словарем данных, а используете обычный синтаксис ALTER TABLE t ADD/MODIFY/DROP CONSTRAINT.

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

1) Убедитесь, что никто не изменяет данные, пока выполняется эта операция.

2) Сначала отбросьте старые ограничения внешнего ключа, чтобы избежать конфликта имен с новыми ограничениями.

3) Отбросьте старые ограничения первичного ключа

4) Создайте новые ограничения первичного ключа в столбцах guid.

5) Создайте новые ограничения внешнего ключа

И тогда вы сделали.

С уважением, Роб.

person Rob van Wijk    schedule 06.05.2010
comment
Хорошо, ALTER TABLE, но как мне автоматизировать копирование существующих отношений? Единственный способ, который я могу себе представить, - это запрос отношений в таблице all_cons_cols и user_constraints, создание ее копии для «новых» столбцов и удаление «старых». - person Oxymoron; 06.05.2010
comment
Создайте сценарий, который генерирует команды для вас. Что-то вроде выбора «изменить таблицу» || имя_таблицы || 'убрать ограничение' || имя_ограничения || ';' из user_constraints, где Constraint_type = 'P', чтобы удалить все первичные ключи. И что-то похожее на удаление внешних ключей и создание новых ограничений. - person Rob van Wijk; 07.05.2010
comment
Так что мне нужно использовать таблицу user_constraints точно так же, как я это делаю сейчас ;) Имейте в виду, что мы говорим о реальной базе данных с записями. DISABLE'ing или DROP'ing не будет легко возможным из-за ссылок. - person Oxymoron; 07.05.2010
comment
Что было бы лучшим способом увидеть, в каких таблицах определенный PF упоминается как FK. Скажем, у меня есть таблица «USER» с «USER_ID» в качестве PK, как мне выяснить, в каких других таблицах есть ссылки на столбец «USER_ID». Таким образом, я могу начать отключать ссылки «внизу». - person Oxymoron; 07.05.2010
comment
Хм, у клиента есть жесткое соглашение об именах, которое я могу использовать в своих интересах. - person Oxymoron; 07.05.2010
comment
Вы можете сделать это глупым способом, многократно выполняя удаление ограничений, пока они все не исчезнут, или вы можете сделать это умным способом и использовать столбец r_constraint_name, чтобы увидеть, ссылаются ли на первичный ключ другие внешние ключи. - person Rob van Wijk; 07.05.2010