Снятие ограничений внешнего ключа, ссылочной целостности и гибернации

Question

Мой коллега упомянул, что наш клиентский администратор БД предложил удалить все ограничения внешнего ключа в схеме нашего проекта Oracle DB.Изначально я не был согласен с решением.Я разработчик, а не администратор баз данных.Поэтому позже понял, что может быть несколько причин для решения.Поэтому я пытаюсь получить все за и против этого решения.

Информация о проекте:

1. Приложение Spring с постоянным Hibernate.
2. Oracle 10g DB
3. Есть пакетные задания, использующие только SQL-загрузчик или простой JDBC.

Вот мой список плюсов и минусов (Пожалуйста, исправьте меня, если я ошибаюсь)

Плюсы:

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

2. Действие DELETE Hibernate (включает опцию delete cascading) удаляет записи таблицы внешнего ключа перед удалением записи первичного ключа (т. е. чтобы избежать проблемы ссылочной целостности).).Это поведение одинаково для случая отсутствия внешнего ключа, случая внешнего ключа и случая внешнего ключа с каскадом.Но добавление внешнего ключа приведет к ненужному замедлению операции удаления Oracle.

Минусы

1. Hibernate предоставляет механизм управлениясвязь между объектами и каскадными операциями внутри ассоциации.Но оно никогда не обеспечивает полного решения для ссылочной целостности, которое имеет БД.

2. Ссылочная целостность требуется для тех пакетных заданий, которые используют только SQL-загрузчик или простой JDBC.

Ребята, мне нужен ваш совет по этому вопросу.Если кто-либо из вас является администратором базы данных, укажите причины побочных действий администратора.

Спасибо.

Answer 1

Я никогда не слышал такого предложения от администратора базы данных!От разработчика приложения, да, но никогда от Администратор базы данных .Он не верит.

Том Кайт много раз говорил (например, здесь ): приложения приходят и уходят, но данные - это навсегда.

По своему опыту яработали над базами данных Oracle старше 20 лет.Они начали с Oracle 6 и получили за последние годы до 10 или 11 г - те же данные.Но приложения, которые сидели сверху?Сначала это были Forms 3.0, затем в некоторых случаях они были перенесены на C ++, в некоторых перестроены в Forms 6i, а некоторые перестроены в Application Express.ADF это еще одна возможность, конечно;или, может быть, архитектура SOA ...

Что такого особенного в текущем инструменте разработки приложений , что он внезапно берет на себя работу Oracle в качестве СУБД?

Answer 2

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

Нам пришлось написать «скрипт QC», чтобы обнаружить потерянные строки в отношении каждого отношения таблицы (осиротевшие строки были бы предотвращены ограничением внешнего ключа).

Затем, когда (не если) они произошли, мы должны были иметь правила для разрешения сирот.Возможные варианты:

• Удалить потерянные строки.
• Архивировать потерянные строки.
• Обновить любые значения потерянных внешних ключей в NULL.
• Обновитьлюбые потерянные значения внешнего ключа для некоторого существующего значения в родительской таблице.
• Живите с аномалиями.Напишите больше кода, чтобы исключить сирот из отчетов.Может быть, набор VIEW для всех таблиц?

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

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

Answer 3

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

Например, скажем, у вас есть представление

CREATE VIEW orders_vw AS
SELECT ord.order_id, ord.customer_id, lin.product_id
FROM orders ord JOIN order_lines lin on ord.order_id = lin.order_id

Тогда у вас есть запрос, который делает SELECT product_id FROM orders_vw WHERE order_id = :val При соблюдении целостности база данных знает, что у любого order_id в order_lines есть одна строка в родительской таблице, и, поскольку на самом деле не выбрано значение из таблицы orders, она может сохранить работу, не посещая таблицу orders. Без ограничения база данных не может быть уверена, что у записи в order_lines есть родительский элемент, поэтому она должна выполнить дополнительную работу по просмотру таблицы заказов, чтобы проверить ее.

В зависимости от ваших шаблонов запросов удаление ограничений может фактически увеличить нагрузку на БД.

Answer 4

Обычно удаление внешнего ключа - это то, с чего начинается оптимизация производительности базы данных.Это своего рода компромисс: вы продаете гарантированную целостность на уровне СУБД и должны управлять ею самостоятельно (что довольно просто в Hibernate, но требует очень точной работы в простом SQL), и вы получаете повышенную производительность запросов, поскольку проверки внешних ключей в запросахдовольно дорогие.