Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ
Шрифт:
Общую технику реализации автоинкрементного первичного ключа (при отсутствии ручной работы) см. в разд. "Генераторы" главы 9 ив главе 31.
! ! !
ВНИМАНИЕ! Атомарность ключа должна поддерживаться в приложениях сокрытием его от пользователя или хотя бы его свойством только для чтения.
. ! .
Разработчики баз данных обычно занимают четкую позицию "за" или "против" использования суррогатных ключей. Позиция автора по использованию атомарности очевидна. Несмотря на это, в интересах справедливости аргументы за и против представлены в табл. 14.1.
Таблица 14.1. Суррогатные (искусственные) ключи в сравнении
Особенность | За | Против |
Атомарность | Суррогатные ключи не воспринимаются как данные и никогда не изменяются | Естественные ключи по своей сути нестабильны, потому что они являются предметом человеческих ошибок и внешних изменений |
Удобство | Естественные ключи несут информацию, сокращающую необходимость выполнения соединений или дополнительных чтений для поиска данных в контексте. Естественные ключи более удобны при использовании в интерактивных инструментах запросов | Суррогатные ключи не несут никакой информации помимо их функции связи, требования соединений или подзапросов поиска связанных "осмысленных" данных |
Размер ключа | Суррогатные ключи компактны | Естественные ключи имеют больший размер и часто усложняют составные ключи, которые усложняют запросы и схему |
Навигация | Суррогатные ключи обеспечивают чистую, быструю навигацию по коду | Естественные ключи обычно не являются подходящими при навигации в стиле кода по причине порядка сортировки, денормализации и размера |
Нормализация | Суррогатные ключи могут быть нормализованы в базе данных | Естественные ключи имеют тенденцию к усложнению, распространению денормализации данных внешних ключей |
Должны ли вы проектировать базу данных, смешивая естественные и искусственные ключи? Крайней точкой зрения является последовательный подход в проектировании - выберите естественные или искусственные ключи и применяйте это правило без исключений. Однако более умеренный подход может предоставить лучшее из обоих миров. Практичным является использование естественных ключей для стабильных "управляющих" таблиц соответствия, ключей, которые редко изменяются, никогда не участвуют в составных ключах и часто появляются в выходных данных.
! ! !
ВНИМАНИЕ! При проектировании ключей для базы данных Firebird помните, что ключи порождают индексы, а индексы в Firebird ограничены в размере до 252 байт. Сложные последовательности сортировки и многобайтовые международные наборы символов уменьшают количество символов в данных, которые могут быть использованы в качестве индексов.
. ! .
Индексы не являются ключами. Ключи- ограничения на уровне таблицы. Сервер базы данных реагирует на объявление ограничений созданием множества объектов базы данных для их поддержки. Для ограничений первичных и уникальных ключей он создает уникальный индекс из столбца (столбцов), указанных в ограничениях. Для внешних ключей он создает неуникальный индекс из указанных столбцов, сохраняет записи для отношения и создает триггеры для выполнения нужных действий.
* Ключи являются ограничениями.
* Индексы требуются для поддержания ограничений.
! ! !
ВНИМАНИЕ! Вы не должны создавать свои собственные индексы, которые дублируют создаваемые системой индексы для поддержания ограничений. Это является важной
. ! .
Случайное изменение или удаление строк, имеющих зависимости, разрушает целостность ваших данных. Обычно ссылочная целостность данных является выражением, описывающим уровень, на котором зависимости базы данных защищены от разрушения. В контексте настоящего руководства мы ссылаемся на встроенные механизмы поддержки отношений внешних ключей и выполнения желаемых действий при изменении значения первичного ключа в главной таблице или при удалении строки этой таблицы.
Синтаксис ограничений формальной ссылочной целостности данных Firebird подробно обсуждается в главе 17.
Если внешние ключи являются "кабелями", делающими базу данных реляционной, то индексы могут рассматриваться как поставщики "полосы частот". Хорошее индексирование повышает скорость; отсутствие индексов или плохие индексы замедляют поиск, соединение и сортировку.
Как средство управления реляционной базой данных, Firebird может связать почти любой объект столбца с почти любым другим объектом столбца (за исключением различных типов BLOB, включая массивы) с использованием ссылок на их идентификаторы. Однако при увеличении количества строк, связанных столбцов и таблиц в запросах производительность падает.
Когда столбцы, которые отыскиваются, соединяются и сортируются, индексированы удобным образом, производительность (время выполнения и использования ресурсов) может резко улучшиться. Необходимо также сказать, что слабое индексирование может резко ухудшить производительность!
Firebird использует алгоритмы оптимизации, которые в большой мере основаны на оценке затрат (cost-based). При подготовке запроса оптимизатор вычисляет относительные стоимости использования или игнорирования доступных индексов и возвращает клиенту план запроса, сообщая о своем выборе. Хотя можно разработать и передать оптимизатору ваш собственный план запроса- важное средство серверов реляционных СУБД, которые используют оптимизацию, основанную на правилах, - чаще всего оптимизатор Firebird знает лучше. Планы Firebird являются более полезными в выявлении и устранении проблем с индексами.
Проектирование и создание индексов рассматривается в главе 18.
Firebird предоставляет возможность создания и сохранения предварительно определенных спецификаций запросов, называемых просмотрами (view), которые в большинстве случаев могут рассматриваться просто как если бы они были таблицами. Просмотр является классом наследуемой таблицы, которая хранит данные. Для многих задач - особенно для тех, когда доступ к отдельным столбцам таблиц нужно запретить или когда спецификация отдельного запроса не может предоставить требуемый уровень абстракции - просмотры решают сложные проблемы.
Просмотры и другие наследуемые таблицы обсуждаются в главе 24 и должны изучаться вместе с другими главами части V.
Хранимые процедуры и триггеры являются модулями компилированных, выполняемых кодов, которые выполняются на сервере. Исходный код пишется на расширении языка SQL, называемом процедурным SQL, или PSQL.
Хранимые процедуры могут быть выполняемыми процедурами и селективными процедурами. Они могут получать входные аргументы и возвращать выходные наборы. Выполняемые процедуры выполняются полностью на сервере и могут возвращать набор констант из одной строки (одиночный набор) по завершении выполнения. Селективные процедуры генерируют многострочные наборы из нуля или более строк, которые могут использоваться клиентскими приложениями различными способами, как и любой другой выходной набор.