Мифы о Firebird и InterBase

1. Файл базы данных не может быть больше 2 гигабайт

Не 2, а 4. И не вообще, а в старых версиях InterBase, например в 4.x/5.x. В InterBase 6.0 и выше, в Firebird и Yaffil, такого ограничения нет.

Лимит на размер файла в основном определяется используемой файловой системой того диска, где лежит база данных. Например, для FAT16 это 2 гигабайта, для FAT32 – 4 гигабайта, на NTFS – вам хватит на всю жизнь.

То есть, если у вас в качестве файловой системы выбрана NTFS или другая (на Linux), не имеющая "детского" ограничения на размер файла в 4 гигабайта, то можете не думать про многофайловые БД.

Кстати, даже если вами выбран FAT32, вы можете создать несколько разделов и создать многофайловую базу данных InterBase и Firebird, совокупный размер файлов которой ограничивается размером 131 терабайт.
 

2. InterBase и Firebird – СУБД для очень мелких задач

Зависит от того, что считать мелкой. Если база размером 10-100 гигабайт это мелочь, или количество одновременных пользователей 300-500 – тоже мелочь, то да.
 

3. InterBase и Firebird плохо работают с базами больше 200 мегабайт

Такое может быть если в качестве сервера вы используете Windows 95 или Windows 98 с 64 мегабайтами ОЗУ. InterBase и Firebird отлично работает с базами размером в десятки гигабайт и сотнями пользователей, если сервер нормальный (хотя бы с ОЗУ 1-2 гигабайта). Даже для рабочих станций сейчас рекомендуемый размер памяти – 512 мегабайт, чего вполне хватит для сервера, обслуживающего базу размером 1-10 гигабайт и числом пользователей от 10 до 50.
 

4. Версии записей убираются при Restore (и, соответственно, хранятся в backup), или
gbak -g записывает backup без версий, а по умолчанию – с версиями записей

Ничего подобного. В backup никакие версии записей не хранятся, и никому они там не нужны. Процесс Backup вообще представляет собой обычную транзакцию snapshot (repeatable read), которая читает только те версии записей, которые были на момент ее старта. А за сборку мусорных версий или несборку отвечает флаг no_garbage_collect, который может использоваться и в обычном коннекте в библиотеках прямого доступа (т. е. в приложениях, например для ускорения выборок в некоторых случаях).
 

5. Версии записей создаются при чтении

Версии создаются только при изменении или удалении записей (UPDATE или DELETE). При чтении, наоборот, если обнаруживаются никому не нужные версии одной и той же записи, то онисобираются как мусор (т. е. удаляются. см. статьюLINK). Так что можно хоть обчитаться, но ни к какому созданию новых версий это не приведет. И наоборот, обновление записи создает новую версию этой записи в любом случае, независимо от того, читает еще кто то эту запись, или нет.
 

6. К файлам баз данных (gdb) надо давать доступ (share) пользователям

Не надо этого делать, это совершенно ни к чему. InterBase и Firebird – не файл-сервер, и с базами данных работает сам. Клиент только передает серверу информацию, с какой базой данных он хочет работать, и какие запросы к ней хочет выполнять. Собственно, этот пункт относится скорее к тому, что НЕ надо делать в InterBase и Firebird.
 

7. Я вижу в информации о плане запроса слово NATURAL! О ужас!

Ничего страшного. Таблица, для которой оптимизатор выбрал перебор записей в естественном порядке (natural), может быть небольшой, что вполне оправдано. Или, путем использования natural будет меньше обращений к страницам БД, чем при использовании индекса.
 

8. InterBase и Firebird сделаны для Windows, поэтому под Unix (Linux, Solaris и т. п.) они плохо работает

Ничего подобного. InterBase впервые был создан именно для Unix, и перед тем как вышла Windows-версия, было 15 "портов" под различные Unix (AIX, IRIX, SCO, HP-UX...). Собственно, Windows-версия появилась через 7-8 лет после первой версии InterBase. Firebird, например, имеет "родные" версии как для Windows, так и для множества вариантов Linux/Unix (даже включая MacOS).
 

9. Скомпилированные процедуры хранят планы запросов

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

10. Самые свежие версии InterBase (2007) и Firebird (2.0, 2.1) использовать сложнее, чем InterBase 6.x

Ничего подобного. В отношении быстроты и простоты установки практически ничего не изменилось со времен InterBase 4.0, например. Разумеется, последние версии InterBase и Firebird содержат много новой функциональности и параметров конфигурации. Но никто не заставляет эту новую функциональность вас использовать, а также начинать знакомство с сервером с кручения настроек в конфиге. То есть, если хотите, можете использовать возможности IB 4.x, 5.x или 6.x, в этом случае ваш код будет совместим с любой последней версией InterBase и Firebird.

Конечно, в более новых версиях InterBase и Firebird исправляются ошибки. Если вы писали код (SQL, процедуры, триггеры), который ныне считается ошибочным – да, его придется модифицировать. Но для начинающих использовать старые версии СУБД никакого смысла нет.

Если Вам понравилось, и Вы слышали еще что-нибудь в этом же роде – милости просим, присылайте.

(c) KDV, http://www.ibase.ru