Не 2, а 4. И не вообще, а в старых версиях InterBase, например в 4.x/5.x. В InterBase 6.0 и выше, в Firebird и Yaffil, такого ограничения нет.
Лимит на размер файла в основном определяется используемой файловой системой того диска, где лежит база данных. Например, для FAT16 это 2 гигабайта, для FAT32 - 4 гигабайта, на NTFS - вам хватит на всю жизнь.
То есть, если у вас в качестве файловой системы выбрана NTFS или другая (на Linux) не имеющая "детского" ограничения на размер файла в 4 гигабайта, то можете не думать про многофайловые БД.
Кстати, даже если вами выбран FAT32, вы можете создать несколько разделов, и создать многофайловую базу данных InterBase и Firebird, совокупный размер файлов которой ограничивается размером 131 терабайт.
зависит от того, что считать мелкой. Если база размером 10-100 гигабайт это мелочь, или количество одновременных пользователей 300-500 - тоже мелочь, то да.
Такое может быть если в качестве сервера вы используете Windows 95 или Windows 98 с 64 мегабайтами ОЗУ. InterBase и Firebird отлично работает с базами размером в десятки гигабайт и сотнями пользователей, если сервер нормальный (хотя бы с ОЗУ 1-2 гигабайта). Даже для рабочих станций сейчас рекомендуемый размер памяти - 512 мегабайт, чего вполне хватит для сервера, обслуживающего базу размером 1-10 гигабайт и числом пользователей от 10 до 50.
Ничего подобного. В backup никакие версии записей не хранятся, и никому они там не нужны. Процесс Backup вообще представляет собой обычную транзакцию snapshot (repeatable read), которая читает только те версии записей, которые были на момент ее старта. А за сборку мусорных версий или несборку отвечает флаг no_garbage_collect, который может использоваться и в обычном коннекте в библиотеках прямого доступа (т.е. в приложениях, например для ускорения выборок в некоторых случаях).
Версии создаются только при изменении или удалении записей (UPDATE или DELETE). При чтении, наоборот, если обнаруживаются никому не нужные версии одной и той же записи, то они собираются как мусор (т.е. удаляются. см. статью). Так что можно хоть обчитаться, но ни к какому созданию новых версий это не приведет. И наоборот, обновление записи создает новую версию этой записи в любом случае, независимо от того, читает еще кто то эту запись, или нет.
!Да, версии записей могут создаваться при чтении, но только в Firebird 1.5 и выше при запросах select ... for update with lock. читайте статью.
Не надо этого делать, это совершенно ни к чему. Interbase и Firebird - не файл-сервер, и с базами данных работает сам. Клиент только передает серверу информацию, с какой базой данных он хочет работать, и какие запросы к ней хочет выполнять. Собственно, этот пункт относится скорее к тому, "что НЕ надо делать при работе с Interbase/Firebird".
Ничего страшного. Таблица, для которой оптимизатор выбрал перебор записей в естественном порядке (natural), может быть небольшой, что вполне оправдано. Или, путем использования natural будет меньше обращений к страницам БД, чем при использовании индекса.
Ничего подобного. InterBase впервые был создан именно для Unix, и перед тем как вышла Windows-версия, было 15 "портов" под различные Unix (AIX, IRIX, SCO, HP-UX...). Собственно, Windows-версия появилась через 7-8 лет после первой версии InterBase. Firebird, например, имеет "родные" версии как для Windows, так и для множества вариантов Linux/Unix (даже включая MacOS).
Ничего подобного (если только план запроса не задан явно). Данный миф основан на том, что процедура или триггер после первого вызова (и именно в этот момент вычисляются планы запросов, которые в процедуре написаны) остается в кэше метаданных до тех пор, пока все клиенты, вызывавшие эту процедуру, не отсоединятся. В этом случае действительно, пока процедура находится в памяти, планы запросов не меняются даже если изменится статистика используемых планами индексов.
Ничего подобного. В отношении быстроты и простоты установки практически ничего не изменилось со времен InterBase 4.0, например. Разумеется, последние версии InterBase и Firebird содержат много новой функциональности и параметров конфигурации. Но никто не заставляет эту новую функциональность вас использовать, а также начинать знакомство с сервером с кручения настроек в конфиге. То есть, если хотите, можете использовать возможности IB 4.x, 5.x или 6.x, в этом случае ваш код будет совместим с любой последней версией InterBase и Firebird.
Конечно, в более новых версиях InterBase и Firebird исправляются ошибки. Если вы писали код (SQL, процедуры, триггеры), который ныне считается ошибочным - да, его придется модифицировать. Но для начинающих использовать старые версии СУБД никакого смысла нет.
Если Вам понравилось, и Вы слышали еще что-нибудь в этом же роде - милости просим, присылайте.