Галерея
7757 8119 8300 8698 8817 9504 9722 9937
Интересные записи
Новое на сайте
Новое

Изначально отложенные ограничения

Изначально отложенные ограниченияСостояние ограничения initially deferred обычно используют в особых случаях, например при загрузке массивов данных и их преобразовании. Повседневное использование отложенных ограничений может внести путаницу в базу данных и вызывать большие неудобства. Для примера представьте, что некто направляет в СУБД несколько десятков инструкций DML, после чего подтверждает изменения, однако происходит ошибка, поскольку первая инструкция вставки (insert) нарушает некоторое изначально отложенное ограничение. Будет выполнен откат транзакции, после чего пользователю снова придется вводить все инструкции пакета. Если бы ограничения проверялись после каждой инструкции, перед каждой следующей операцией пользователь знал бы, что в предыдущей введены корректные данные. В реальной жизни могут быть еще более суровые последствия. Иногда критичное ко времени приложение обрабатывает данные несколько часов, а затем завершается ошибкой только потому, что только в одной из вставок были нарушены требования ограничения Выход из ситуации прост — использовать изначально отложенные ограничения только для специальных задач и возвращать режим проверки немедленно по их завершению. Если ограничение создано с параметром deferrable, можно многократно переключаться между разными режимами проверки. Более подробная информация по данному вопросу содержится

В следующем тезисе допускается некоторое упрощение, но в общем случае данные физически хранятся на жестких дисках сервера баз данных. Точное описание физической природы хранения информации в СУБД выходит за рамки книги, однако мы все-таки затронем основы, чтобы полнее раскрыть процесс создания объектов базы данных. В разных СУБД используют разные подходы, однако общая идея остается одной и той же: иметь возможность разделять объекты базы данных по типу и, в идеальном случае, помещать их на разные диски ради ускорения операций с базой данных. К примеру, все таблицы могут храниться на одном жестком диске, все индексы — на другом, а все особо крупные объекты — на третьем. Важность такого подхода зависит от конкретной реализации СУБД; значительную роль играют и другие факторы, такие как размер базы данных, ее нагрузка, качество сервера и т. д.