Оценка памяти сервера включает множество факторов.

* Работа сервера Firebird. Сервер Firebird осуществляет эффективное использование ресурсов сервера. Суперсервер (Superserver) после старта использует приблизительно 2 Мбайта памяти. Классический сервер (Classic server) в POSIX не использует памяти, пока не установлено клиентское соединение. В Windows небольшие сервисы прослушивают запросы на соединения.

* Клиентские соединения. Каждое соединение с Суперсервером добавляет приблизительно 115 Кбайт, больше или меньше, в соответствии со стилем и характеристиками клиентских приложений, а также спроектированной схемой базы данных. Каждое соединение с Классическим сервером использует приблизительно 2 Мбайта (в зависимости от количества применяемых соединением таблиц, триггеров, процедур и других объектов - может быть и до 30-40 Мбайт. Для баз данных среднего размера - от 4 до 15 Мбайт).

* Кэш базы данных. Значение по умолчанию может конфигурироваться - в страницах базы данных. Суперсервер использует единый кэш (с размером по умолчанию 2048 страниц) для всех соединений и автоматически увеличивает кэш при необходимости. Классический сервер создает индивидуальный кэш (по умолчанию 75 страниц) на каждое соединение.

На основании существующих оценок отводите 64 Мбайта RAM для сервера и 16 Мбайт для локального клиента. Чем больше клиентов вы добавляете, тем больше памяти будет использовано. Базы данных с большим размером страниц используют ресурсы из большего участка памяти, чем базы данных с меньшим размером страниц. Использование ресурсов для Классического сервера увеличивается линейно с каждым новым подключением клиента; для Суперсервера ресурсы разделяются между несколькими подключениями, и будут динамически увеличиваться при необходимости. Firebird 1.5 будет использовать для сортировки, если она необходима, дополнительную RAM. Использование памяти более подробно обсуждается в главе 6.

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

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

[2]

.

Минимальные требования зависят от того, как вы планируете использовать систему. Вы можете запустить сервер и разрабатывать схемы баз данных на персональном компьютере с минимальной конфигурацией- даже на "быстром" 486 или на Pentium II с 64 Мбайт RAM будет работать Firebird 1.0.x- но такая конфигурация не позволит использовать многие возможности при работе в сети. Для версии 1.5 и более поздних процессор 586 с 128 Мбайт RAM может рассматриваться как минимум. Windows более требовательна к CPU и оперативной памяти, чем Linux, в которой запускается сервер на консольном уровне. Версии операционной системы влияют на требования: некоторые платформы UNIX требуют больше ресурсов как для сервера, так и для клиента, а требования некоторых версий Windows неприменимы к указанным характеристикам, независимо от требований программного обеспечения.

Суперсервер и Классический сервер Firebird могут использовать разделяемую память мультипроцессоров в Linux. В Windows поддержка SMP (симметричный мультипроцессор) доступна только для Классического сервера.

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

Каждый инсталляционный комплект содержит все компоненты, нужные для инсталляции Firebird.

* Исполняемая программа сервера Firebird.

* Множество других программ, нужных при инсталляции и/или во время выполнения задач.

* Скрипты командной строки или командные файлы, нужные при инсталляции, которые также могут использоваться как утилиты сервера.

* Файл безопасности баз данных (isc4.gdb для версии 1.0.x; security.fdb для версии 1.5).

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

Обычно первой частью имени является строка "Firebird".

* Если релиз для Windows поддерживает Классический сервер, он будет включен в тот же инсталлятор, что и Суперсервер.

Когда вы найдете требуемый комплект поставки, щелкните мышью по гиперссылке - имени файла. Вы перейдете на список зеркальных сайтов, как показано на рис. 1.1.

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

Средства локального доступа.

* Локальная заглушка TCP/IP. Для многоуровневых серверных приложений и других клиентов доступ к локальному серверу на любой поддерживаемой платформе осуществляется через протокол TCP/IP: даже при отсутствии сетевой карты соединение может быть выполнено через специальный сервер localhost с IP-адресом 127.0.0.1.

! ! !

ВНИМАНИЕ! Соединение с localhost невозможно для приложений встраиваемого сервера.

Начиная с Firebird 1.5, пакеты Firebird для Windows включают полную функциональность встраиваемого сервера (клиент и сервер соединяются как динамическая библиотека). Это идентично обычной модели клиент-сервер, за исключением того, что здесь не поддерживается сетевой протокол: соединение осуществляется в стиле "локальной Windows" для эмуляции сетевого соединения.

! ! !

ВНИМАНИЕ! Встраиваемый сервер не поддерживает пароль безопасности доступа Firebird.

. ! .

Каталог инсталляции по умолчанию /opt/firebird. В каталоге /bin находится в двоичном формате сервер Firebird fbserver (ibserver для Firebird 1.0.x), который запускается как процесс-демон в Linux/UNIX. Он запускается автоматически после инсталляции посредством RPM или скрипта и каждый раз при перезагрузке сервера запуском скрипта демона firebird, находящегося в /etc/rc.d/init.d (или /etc/init.d в SuSE), который вызывает утилиту командной строки Firebird Manager - fbmgr.bin. Firebird Manager может быть использована из командной строки для запуска и остановки процесса вручную.

Если вы по разным причинам запустили Firebird вручную, соединитесь с ним как пользователь root или firebird. Запомните, какую учетную запись вы использовали при запуске fbserver, потому что все созданные объекты будут принадлежать пользователю с этой учетной записью. Если позже другой пользователь запустит процесс с использованием другой учетной записи пользователя, то эти объекты будут ему недоступны.

Настоятельно рекомендуется создать системного пользователя с именем firebird и запускать сервер Firebird с этой учетной записью.

Классический сервер Firebird использует процессы xinetd или inetd для обработки поступающих запросов. (Применяемый процесс зависит от версии Linux.) Нет необходимости явно запускать сервер. Процесс xinetd или inetd запускается автоматически; когда он получает запрос от клиента Firebird на соединение, он порождает копию процесса fbinetserver для этого клиента.

Если Классический сервер Firebird был установлен инсталлятором, использующим скрипты или RPM, то файл конфигурации запуска для fb inet server с именем firebird должен быть добавлен в сервисы, о которых знает [x]inetd. В большинстве дистрибутивов Linux этот файл размещается в каталоге /etc/xinetd.d. Чтобы [x]inetd "слушал" запросы на соединение от клиентов для вашего Классического сервера Firebird, скрипт firebird должен находиться в том же каталоге, где стартует процесс [x]inetd.

Выполняемая программа Суперсервера Firebird - fbserver.exe. Хотя он может запускаться и как самостоятельная программа, он также может находиться под управлением Guardian - fbguard.exe. Guardian обеспечивает возможность эмулировать автоматический рестарт сервисов в Windows и POSIX, запущенных с переключателем -forever. Если приложение fbserver.exe аварийно завершается, Guardian пытается заново его запустить. Рекомендуется использовать Guardian на хостах, работающих на платформах Windows 95/98 и ME, а также NT/XP, если сервер выполняется как приложение.

В Windows NT и Windows 2000 программа сервера Firebird может выполняться как сервис и как приложение. Инсталляция по умолчанию устанавливает сервер Firebird - и Guardian, если выбран - для автоматического выполнения как сервисы. Вариант выполнения для обоих может быть изменен, чтобы они выполнялись как приложения.

В Windows 95/98, ME и XP Home Edition Firebird может выполняться только как приложение. Если Firebird выполняется как приложение, на панели задач появляется соответствующая иконка. Некоторые задачи администрирования могут быть выполнены вручную при щелчке правой кнопкой мыши на этой иконке.

Если данный компьютер используется как сервер БД, то вам настоятельно рекомендуется выполнять сервер Firebird как сервис.

! ! !

ПРИМЕЧАНИЕ. Пользователи, выполняющие миграцию с InterBase 6.0 или более раннего, должны обратить внимание, что не требуется выполнения Firebird как приложения на хост-машинах SMP, чтобы установить наличие только одного процессора. Опция сервиса Firebird по использованию количества процессоров содержится в файле конфигурации. Более подробную информацию см. в разд. "Файл конфигурации Firebird" главы 36.

. ! .

Когда Firebird выполняется как сервис, небольшое количество административных задач, включая останов и рестарт, может быть решено с использованием апплета Firebird Manager на Панели управления. Самый простой апплет инсталлируется при установке Firebird. Более сложные апплеты, включая версии языков, можно загрузить из Firebird CVS с сайта SourceForge или с различных сайтов, связанных с Firebird.

Средство алиасов включает файл конфигурации aliases.conf. Он находится в корневом каталоге вашей инсталляции сервера и не должен перемещаться оттуда.

До реализации 1.5 все клиентские приложения соединялись с сервером, используя строку соединения, которая включала абсолютный путь к серверу. Формат абсолютного пути меняется в зависимости от того, выполняется ли сервер под Windows или на POSlX-совместимой платформе (Linux, UNIX и т.д.), а для серверов под Windows еще и от того, какой вид сетевого соединения используют клиенты - TCP/IP или NetBEUI.

Предположим, у вашего сервера имя hotchicken. Если сервер выполняется на POSIX- совместимой платформе; клиенты TCP/IP будут соединяться с базами данных, используя строку соединения следующего формата:

hotchicken:/opt/databases/Employee.fdb

Если же сервер работает под Windows, клиенты TCP/IP должны соединяться, используя другой формат пути:

hotchicken:D:\databases\Employee.fdb

Основное преимущество средства алиасов в том, что оно может быть использовано в комбинации с параметром DatabaseAccess = NONE из файла firebird.conf для ограничения доступа к файлам баз данных - доступ разрешен только к файлам, указанным в aliases.conf.

Алиасы баз данных появились в Firebird 1.5. Для их использования отредактируйте файл aliases.conf в корневом каталоге инсталляции Firebird, используя текстовый редактор, такой как Блокнот (в Windows) или V1 (Linux).

Инсталлированный файл aliases.conf выглядит приблизительно таким образом:

Доли секунды, если хранятся, являются десятитысячными долями секунды для всех типов даты и времени.

Ошибочно предполагать, что тип TIME может хранить интервал времени. Он не может. Для вычисления интервала времени вычтите более позднюю дату или время из более раннего. Результатом будет число NUMERIC(18,9), выражающее интервал в днях. Поскольку точность теряется, доли секунд надо рассматривать как миллисекунды, а не десятитысячные доли секунд. Используйте обычные арифметические операции для конвертирования дней в часы, минуты или секунды, как вам требуется.

Предположим, что столбцы STARTED и FINISHED имеют тип TIMESTAMP (DATE В диалекте 1). Для вычисления и сохранения в столбце TIME_ELAPSED типа DOUBLE PRECISION интервала времени в минутах вы можете использовать следующее

[25]

:

UPDATE ATABLE

SET TIME_ELAPSED = (FINISHED - STARTED) * 24 * 60

Firebird имеет два предварительно определенных типа BLOB, отличающиеся атрибутом подтипа (ключевое слово в SQL SUB_TYPE), как описано в табл. 12.1.

Таблица 12.1. Предварительно определенные подтипы BLOB

Данные BLOB хранятся в различных форматах в обычном столбце данных и вне столбца. Они хранятся в виде сегментов на одной или более страницах базы данных. Сегменты являются дискретными фрагментами неформатированных данных, которые обычно создаются приложением в виде потока и передаются функциям API для пакетирования и передачи по сети по одному блоку за раз непрерывно.

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

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

Поскольку в Firebird не существует никакого синтаксиса динамического SQL для обработки типов ARRAY, выполнение DML и поиск таких типов из интерфейсов динамического SQL (DSQL) не является простым делом. API Firebird содержит структуры и функции, позволяющие динамическим приложениям работать с ними напрямую. Некоторые компоненты доступа к данным RAD (например, iBObject, использующиеся в продуктах Borland Delphi и Kylix) содержат классы, инкапсулирующие эту функциональность API в виде свойств и методов клиентской стороны.

ESQL, который не использует структуры и вызовы функций API, поддерживает некоторый статический синтаксис SQL для обработки типов ARRAY и интеграции их с массивами, объявленными во включающем языке.

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

Использование массивов является подходящим, когда:

* элементы данных естественно принимают вид множества данных одного типа;

* весь набор элементов данных в одном столбце базы данных должен быть представлен и должен управляться как одно целое вместо того, чтобы сохранять каждый элемент в отдельном столбце;

* к каждому элементу также должен быть индивидуальный доступ;

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

Массивы могут содержать элементы любого поддерживаемого Firebird типа за исключением BLOB. Массивы массивов не поддерживаются. Все элементы конкретного массива имеют один и тот же тип данных.

Массив может быть определен как домен (с использованием CREATE DOMAIN) или как столбец в операторе CREATE TABLE или ALTER TABLE. Определение домена или столбца как массива похоже на определение любого другого такого объекта, здесь только добавляется указание размерности массива. Размерность массива заключается в квадратные скобки и следует за спецификацией типа данных.

Например, следующий оператор определяет обычный символьный столбец и столбец в виде одноразмерного символьного массива, содержащего восемь элементов:

CREATE TABLE ATABLE (ID BIGINT,

ARR_CHAR(14)[8] CHARACTER SET OCTETS);

/* хранит 1 строку по 8 элементов */

Основные структуры базы данных - ее таблицы, просмотры и индексы - создаются с использованием подмножества языка SQL Firebird, известного как язык определения данных (Data Definition Language, DDL). Оператор DDL начинается с одного из ключевых слов CREATE, ALTER, RECREATE или DROP, которые означают создание, изменение, пересоздание или удаление одного объекта, соответственно. База данных, ее объекты, правила и отношения объединяются для формирования структуры реляционной базы данных.

Firebird хранит метаданные в множестве таблиц, которые он создает прямо в базе данных, - в системных таблицах. Идентификаторы всех системных таблиц начинаются с символов "RDB$". Например, таблица, которая хранит определения и другую информацию о структурах всех таблиц в вашей базе данных, называется RDB$RELATIONS. Связанная с ней таблица RDB$RELATION_FIELDS хранит информацию и описания всех столбцов в каждой таблице.

Такая "база данных в базе данных" является высоко нормализованной. Операторы DDL разработаны для выполнения безопасных операций с таблицами метаданных и в полном соответствии с каскадными эффектами.

Возможно изменение данных в системных таблицах посредством обычных операций SQL. Некоторые инструменты администратора, такие как isql и gfix, выполняют внутренние изменения данных в системных таблицах. При этом, будучи сложной системой управления базами данных, Firebird не была разработана в предположении, что конечный пользователь будет манипулировать строками системных таблиц.

! ! !

До создания базы данных вы должны знать, где собираетесь ее создавать. Это не столь глупо, как звучит. Оператор CREATE DATABASE (альтернатива- CREATE SCHEMA) будет создавать файл или файлы с указанными вами именами, однако он не может создать каталоги и не может изменить полномочия доступа файловой системы. Этим деталям следует уделить внимание в первую очередь.

Дополнительно сервер Firebird 1.5 может быть сконфигурирован для ограничения размещения баз данных. Проверьте параметр DatabaseAccess в файле firebird.conf (см. главу 3), чтобы выяснить, где ваш сервер ограничен в доступе. Если у вас установки по умолчанию (Full), то вы можете создавать базу данных в любом месте. Иначе:

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

* установка None позволяет серверу соединяться только с базами данных, находящимися в списке в aliases.conf. Вы можете создавать базу данных в любом месте, однако, за исключением создания, никакой клиент не будет иметь возможности соединиться с ней, если алиас БД и ее абсолютный адрес не будут присутствовать в aliases.conf.

Метаданные- физические описания таблиц, их столбцов и атрибутов, так же как и описания всех других объектов - сами хранятся в обычных таблицах Firebird внутри базы данных. Сервер Firebird изменяет данные в этих таблицах, когда объекты базы данных создаются, изменяются или удаляются. Он постоянно к ним обращается при выполнении операций над строками. Такие таблицы называются системными таблицами. Более подробную информацию см. в разд. "Системные таблицы" в самом начале главы 14. Схемы системных таблиц см. в приложении 9.

Когда создается таблица, Firebird автоматически применяет к ним безопасность схемы по умолчанию. Человеку, который создает таблицу (ее владелец), назначаются к ней все привилегии SQL, включая право передавать привилегии другим пользователям, триггерам и хранимым процедурам. Ни один другой пользователь, за исключением SYSDBA, не будет иметь никакого доступа к этой таблице, пока явно не получит привилегии.

! ! !

ВНИМАНИЕ! Эта защита будет столь же хороша (или плоха), сколь и защита доступа к вашему серверу. Любой, кто может соединиться с вашим сервером, сможет создать базу данных. Любой, кто может соединиться с вашей базой данных, сможет создавать в ней таблицы. Firebird 1.5 несколько улучшает эту печальную ситуацию, позволяя вам ограничивать размещения, где могут создаваться базы данных. См. параметр DatabaseAccess в файле firebird.conf.

. ! .

Ограничения целостности устанавливают правила, которые управляют состоянием доступных элементов данных или отношением между столбцом и таблицей, как целое - часто и тем, и другим. Примерами являются NOT NULL (не допускает ввод, содержащий неопределенное значение), UNIQUE (требует, чтобы вводимый элемент не имел соответствующего значения этого столбца в таблице) и PRIMARY KEY (объединяет два других ограничения, а также "представляет" таблицу для ссылочного отношения с другими таблицами).

Каждое из ограничений целостности подробно обсуждается позже в этой главе.

Ссылочное ограничение реализовано как FOREIGN KEY. Ограничение внешнего ключа существует только в контексте другой таблицы и уникального ключа этой таблицы, заданного явно или неявно в предложении REFERENCES при объявлении ограничения.

Таблицы, связанные в отношении внешнего ключа, называются связанными ограничением ссылочной целостности. Следовательно, любой столбец или группа столбцов, ограниченная в ограничениях PRIMARY KEY или UNIQUE, также потенциально являются субъектами ссылочных ограничений.

Ссылочная целостность подробно обсуждается в главе 17.

Firebird не поддерживает атрибут указания допустимости пустого значения, как это делают некоторые нестандартные СУБД. В соответствии со стандартами все столбцы в Firebird могут содержать пустое значение, если не будет явно указано ограничение NOT NULL. Необязательное ограничение NOT NULL является ограничением на уровне столбца, которое может быть применено, чтобы заставить пользователя вводить значение. NULL не является значением, так что любая попытка ввести NULL В столбец или установить его в значение NULL приведет к исключению.

Поскольку роль ограничения NOT NULL заключается в формировании ключей, вы должны знать относительно него некоторые ограничения.

* Оно должно применяться к определению любого столбца, который будет включен в ограничение PRIMARY KEY или UNIQUE.

* В Firebird 1,0.x оно должно применяться к определению любого столбца, который будет включен в ограничение UNIQUE или в уникальный индекс.

* Оно не может быть удалено из домена или столбца операторами ALTER DOMAIN или ALTER TABLE, ALTER COLUMN или перекрыто на уровне столбца. Не используйте домен NOT NULL для определения столбца, который может иметь значение NULL.

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

Если вы пришли в Firebird из СУБД, которые поддерживают концепцию "первичного индекса" для определения ключа (обычно основанные на файлах системы, такие как Paradox, Access и MySQL), то Firebird и мир стандартов SQL вам понятны. Первичный ключ является не индексом, а ограничением. Одним из правил для такого ограничения является то, что ограничение должно иметь определенный уникальный индекс из одного или более связанных с ним непустых элементов.

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

! ! !

Ограничение CHECK используется для проверки достоверности вводимых значений данных. Оно реализует условия или требования, которым должно удовлетворять значение для успешного добавления или обновления. Оно не может изменять вводимое значение; оно лишь вернет исключение проверки достоверности, если значение не будет соответствовать условию.

! ! !

СОВЕТ. Ограничения CHECK применяются после выполнения триггеров "before". Используйте триггер, если вы хотите выполнить проверку и присвоить данным допустимые значения.

. ! .

Ограничение UNIQUE, как и ограничение первичного ключа, гарантирует, что никакие две строки не будут иметь то же значение указанного столбца или группы столбцов. Вы можете объявить для таблицы более одного ограничения UNIQUE, но оно не может использовать тот же набор столбцов, который был использован для ограничения PRIMARY KEY или другого UNIQUE.

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

В Firebird 1.0.x атрибут NOT NULL должен быть применен для всех столбцов, с которыми оперирует ограничение UNIQUE.

Как и ограничение PRIMARY KEY, UNIQUE создает свой постоянный уникальный индекс для поддержания его правил. Правила именования ограничения и индекса соответствует тем же правилам поведения, применимым к другим ключам. Следующий пример isql иллюстрирует именование в Firebird 1.5:

Не импортируйте "первичные индексы" таблиц при миграции из другой СУБД. Есть две важные причины отказаться от таких индексов.

* Многие существующие системы используют иерархические структуры индексов для реализации ссылочной целостности. Базы данных SQL не используют подобную логику для реализации ссылочной целостности. Такие индексы обычно влияют на логику оптимизатора Firebird.

* Firebird создает свои собственные индексы для поддержки ограничений первичного и внешнего ключей, независимо от любого существующего индекса. Как было сказано ранее, дублирование индексов приводит к проблемам для оптимизатора и должно быть полностью исключено.

Направление сортировки индексов в Firebird является важным. Ошибочно было бы предполагать, что один и тот же индекс может быть использован для сортировки или поиска "в обоих направлениях" - от меньшего к большему и от большего к меньшему. В практике индексы ASC (ASCENDING, в возрастающем порядке) помогут в поиске относительно небольшого количества значений, в то время как индексы DESC (DESCENDING, В убывающем порядке) будут полезными при большом количестве значений.

Если автоматический индекс ASC (по умолчанию), то не будет проблем, если вам нужно определить индекс DESC, использующий тот же столбец (столбцы). Обратное также верно: в Firebird 1.5 и выше вы можете выбрать для автоматически создаваемых индексов убывающий порядок. Оптимизатор не "расстроится", если вы также создадите возрастающий индекс для тех же столбцов.