СУБД MS SQL 6.5 использует устройства (devices), которые могут представлять собой файлы или «чистые» разделы (raw partitions, разделы без файловой системы), чтобы работать с данными. Это ведет к сложным для поддержки системам. СУБД MS SQL 7 и MS SQL 2000 используют обычные файлы вместо устройств. Для каждой базы данных создаются, как минимум, два файла: один, собственно, для хранения данных, и второй - для сохранения журнала выполненных транзакций.

СУБД Firebird не использует отдельный журнал для сохранения выполненных транзакций, и поэтому использует единственный файл для хранения всех данных.

Оператор CREATE DATABASE («создать базу данных») в СУБД Firebird проще, чем аналогичный оператор в СУБД MS SQL. Обратитесь к справочнику SQL для подробного описания всех возможностей.

Существенное различие в модели управления файлами - это использование СУБД групп файлов (filegroups) для деления базы данных на несколько наборов файлов по определенному принципу. СУБД Firebird так же может работать с разбитой на несколько файлов базой данных, но модель работы с файлами более проста (в смысле принципа, из которого производится разбиение на файлы - прим. перев.).

Дополнительная возможность, предоставляемая СУБД Firebird - это использование теневых файлов (shadow files). Теневые файлы являются немедленной копией исходной базы данных. Обычно они используются для быстрого получения актуальной копии. В СУБД MS SQL нет такой функции, хотя СУБД MS SQL 2000 имеет похожую функцию при использовании журналов, перемещенных между серверами, и репликации.

СУБД MS SQL 6.5 предоставляет два объекта для управления: «логины» и «пользователи». «Логин» определяет комбинацию имени пользователя и пароля для досутпа к серверу базы данных; «пользователь» определяет права доступа для каждой базы данных. «Логины» отображаются на «пользователей» в базе данных.

В СУБД MS SQL 7 добавлен новый объект управления группами пользователей - «роли». «Роль» является хранилищем прав. Некоторые «роли» являются предопределенными, например, «оператор создания копии базы данных» или «администратор базы данных».

СУБД Firebird предоставляет похожую модель, но не включает в нее «логины». Пользователи сообщают серверу свое имя, пароль и «роль», с правами которой они хотят работать. Существует одна общая база данных для всего сервера баз данных, в которой хранится информация обо всех пользователях сервера (их имена и пароли); информация о «ролях» и предоставленных каждому пользователю правах хранится в каждой конкретной базе данных. (Исходный документ имеет здесь неточность: там сказано, что в базе данных безопасности/пользователей хранится так же информация о «ролях» и разрешениях/запретах для каждого пользователя. Так же версия 2.0 СУБД Firebird вносит много изменений в модель управления пользователями. - прим. перев.)

В обоих СУБД считается хорошей практикой получать доступ к ресурсам через хранимые процедуры (stored procedures), и предоставлять доступ к данным только этим хранимым процедурам. (Это утверждение спорно и не может слепо применяться во всех случаях, по крайней мере, относительно СУБД Firebird. - прим. перев.)

СУБД Firebird использует более простую модель создания резервных копий баз данных и восстановления из них по сравнению с СУБД MS SQL, хотя в качестве жертвы здесь принесена гибкость. Резервное копирование может выполняться с помощью консольных (из командной строки) и графических утилит, в любом случае производится резервное копирование всей базы данных. Операция восстановления также восстанавливает всю базу данных. Нет возможности создания резервной копии только изменений, произошедших с момента создания последней резервной копии, или восстановления изолированного набора транзакций. (В СУБД Firebird 2.0 появилась возможность создания инкрементных резервных копий. - прим. перев.)

Обратите внимание, что при создании резервной копии базы данных СУБД Firebird существует важный параметр, определяющий формат создаваемой резервной копии: платформозависимый или платформонезависимый (переносимый). Создание резервной копии в переносимом формате позволяет администратору базы данных создать ее резервную копию в одной операционной системе, а затем восстановить базу данных из этой копии в другой операционной системе. Обычно такая возможность используется, например, при разработке приложения на Windows, а затем переносе базы данных на более мощный сервер Linux. (Так же, это рекомендуемый способ переноса баз данных с одного компьютера на другой даже для одной операционной системы: простое копирование файла базы данных не рекомендуется. - прим. перев.)