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 мегабайт
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. Скомпільовані процедури зберігають плани запитів
Нічого подібного (якщо тільки план запиту не заданий явно). Даний міф заснований на тому, що процедура або тригер після першого виклику (і саме в цей момент обчислюються плани запитів, які в процедурі написані) залишається в кеші метаданих до тих пір, поки всі клієнти, що викликали цю процедуру, не отсоединятся. У цьому випадку дійсно, поки процедура знаходиться в пам'яті, плани запитів не змінюються навіть якщо зміниться статистика використовуваних планами індексів.
Нічого подібного. Відносно швидкості і простоти установки практично нічого не змінилося з часів InterBase 4.0, наприклад. Зрозуміло, останні версії InterBase і Firebird містять багато нових функцій і параметрів конфігурації. Але ніхто не змушує цю нову функціональність вас використовувати, а також починати знайомство з сервером з крутіння налаштувань в конфіги. Тобто, якщо хочете, можете скористатися наявними можливостями IB 4.x, 5.x або 6.x, в цьому випадку ваш код буде сумісний з будь-останньою версією InterBase і Firebird.
Звичайно, в новіших версіях InterBase і Firebird виправляються помилки. Якщо ви писали код (SQL, процедури, тригери), який нині вважається помилковим - так, його доведеться модифікувати. Але для початківців використовувати старі версії СУБД ніякого сенсу немає.
Якщо Вам сподобалося, і Ви чули ще що-небудь в цьому ж роді - ласкаво просимо, надсилайте.