1. Fișierul bazei de date nu poate fi mai mare de 2 gigaocteți
Nu 2, ci 4. Și deloc, dar în versiunile mai vechi ale InterBase, de exemplu în 4.x / 5.x. În InterBase 6.0 și în versiunea superioară, în Firebird și Yaffil, nu există o astfel de restricție.
Limita dimensiunii fișierului este determinată în principal de sistemul de fișiere al discului în care este localizată baza de date. De exemplu, pentru FAT16 este de 2 gigaocteți, pentru FAT32 - 4 gigaocteți, pentru NTFS - veți avea destine pentru viață.
Asta este, dacă ar fi sistemul ales de fișiere NTFS sau alta (pe Linux), care nu are „copii“ restricții privind dimensiunea fișierului de 4 GB, puteți să nu se gândească la o bază de date multifișier.
Apropo, chiar dacă ați ales FAT32, puteți crea mai multe partiții și puteți crea o bază de date multi-file InterBase și Firebird, dimensiunea totală a fișierelor fiind limitată la dimensiunea de 131 terabytes.
2. InterBase și Firebird - DBMS pentru sarcini foarte mici
Depinde de ceea ce este considerat superficial. În cazul în care dimensiunea bazei de date de 10-100 gigabytes este un lucru mic, sau numărul de utilizatori simultani de 300-500 este, de asemenea, un mic, atunci da.
3. InterBase și Firebird nu funcționează bine cu bazele de date mai mult de 200 megaocteți
4. Versiunile de înregistrări sunt șterse cu Restore (și, prin urmare, sunt stocate în copie de rezervă), sau
gbak -g scrie backup fără versiuni și implicit cu versiuni de înregistrări
Nimic de genul ăsta. În copia de siguranță, nu sunt stocate nici o versiune a înregistrărilor și nu sunt necesare de nimeni. proces de backup, în general, este un instantaneu comună de tranzacție (citire repetabile), care citește numai acele versiuni ale înregistrărilor care au fost, la momentul lansării sale. Un ansamblu pentru versiunile de gunoi sau nesborku pavilion no_garbage_collect responsabil care poate fi utilizat într-o conexiune în biblioteci convenționale DSS (m. E. În aplicații, cum ar fi accelerarea probelor în unele cazuri).
Versiunile de înregistrare sunt create atunci când citiți
Versiunile sunt create numai când modificați sau ștergeți înregistrări (UPDATE sau DELETE). Când citiți, dimpotrivă, dacă găsiți vreo versiune a aceleiași înregistrări care nu este dorită de nimeni, atunci acestea sunt colectate ca gunoi (adică sunt șterse, vedeți articolul LINK). Deci, puteți cel puțin să răspundem, dar nu va duce la crearea de noi versiuni. În schimb, actualizarea unei înregistrări creează în orice caz o nouă versiune a acestei înregistrări, indiferent dacă altcineva le citește sau nu.
6. Fișierele de bază de date (gdb) ar trebui să aibă acces (partajare) utilizatorilor
Nu face asta, este complet inutil. InterBase și Firebird - nu un server de fișiere și cu bazele de date care se execută. Clientul trimite doar informații către server, cu ce bază de date vrea să funcționeze și ce cereri dorește să facă. De fapt, acest punct este mai degrabă la faptul că nu este necesar să se facă în InterBase și Firebird.
7. Vad cuvântul NATURAL în informațiile planului de interogare! O groază!
E în regulă. Tabelul pentru care optimizatorul a ales să caute înregistrările în ordine naturală poate fi mic, ceea ce este complet justificat. Sau, folosind naturale, vor exista mai puține hit-uri la paginile bazei de date decât utilizarea unui index.
8. InterBase și Firebird sunt create pentru Windows, deci în Unix (Linux, Solaris etc.) nu funcționează bine
Nimic de genul ăsta. InterBase a fost creat pentru Unix, iar înainte de lansarea versiunii Windows erau 15 porturi pentru diferite Unix (AIX, IRIX, SCO, HP-UX). De fapt, versiunea Windows a apărut la 7-8 ani de la prima versiune a InterBase. Firebird, de exemplu, are versiuni "native" atât pentru Windows, cât și pentru o varietate de variante Linux / Unix (inclusiv MacOS).
9. Procedurile compilate stochează planurile de interogare
Nimic de fel (cu excepția cazului în care planul de interogare este specificat explicit). Acest mit se bazează pe faptul că procedura sau declanșatorul după primul apel (și a fost în acest moment sunt calculate planurile de interogare care sunt scrise în procedura) rămâne în cache-ul de metadate, atâta timp cât toți clienții, solicită procedura fără a deconecta. În acest caz, într-adevăr, până când procedura este în memorie, planurile de interogare nu sunt modificate chiar dacă modificați statisticile utilizate planurile indici.
Nimic de genul ăsta. În ceea ce privește viteza și ușurința de instalare, nu sa schimbat nimic de la InterBase 4.0, de exemplu. Desigur, cele mai recente versiuni ale InterBase și Firebird conțin o mulțime de noi funcționalități și parametri de configurare. Dar nimeni nu forțează această nouă funcționalitate să vă folosească și, de asemenea, să înceapă cunoașterea cu serverul cu ajustarea setărilor din config. Adică, dacă doriți, puteți utiliza capabilitățile IB 4.x, 5.x sau 6.x, caz în care codul dvs. va fi compatibil cu cea mai recentă versiune a InterBase și Firebird.
Desigur, în versiunile mai noi ale erorilor InterBase și Firebird sunt fixate. Dacă ați scris codul (SQL, proceduri, declanșatoare), care acum este considerat eronat - da, va trebui să fie modificat. Dar pentru incepatori sa foloseasca vechea versiune a bazei de date nu are sens.
Dacă ți-a plăcut și ai auzit altceva de același fel - întreba-te, trimite.
Trimiteți-le prietenilor: