Firebird 2, un database open che sfida i big

Continua a crescere e maturare il database open source che, con la nuova versione 2.0, si arricchisce di funzionalità ancor più avanzate e di maggiori stabilità e performance. Ecco le principali novità

Praga - Frutto di quasi due anni di lavoro, Firebird 2.0 è la nuova versione di un database relazionale open source che in questi anni ha saputo conquistare la fiducia di un crescente numero di utenti. Con la release 2.0 gli sviluppatori affermano di aver riprogettato ampie porzioni del proprio software, migliorando aspetti chiave quali stabilità, performance e sicurezza.

Firebird è apprezzato soprattutto per la completa implementazione degli standard ANSI SQL-92 e SQL-2003, l'efficiente meccanismo di concorrenza e il potente linguaggio a supporto per le stored procedure ed i trigger. Stando ai suoi supporter, Firebird è uno dei più potenti RDBMS (Relational Database Management System) oggi disponibili sul canale open source.

Tra i pregi di questo database vi è la capacità di girare su di un elevato numero di piattaforme, incluse Windows, Linux, Mac OS X e diverse varianti di Unix.
Tra le novità di Firebird 2.0 vi sono un'ottimizzazione del sistema di indicizzazione e di ricerca, un sostanziale incremento dei limiti relativi alle dimensioni dei file indici e delle tabelle, il pieno supporto alle architetture x86 a 64 bit, e un migliorato supporto alla crittografia e alle tabelle derivate delle specifiche SQL200x. C'è poi da segnalare che ora quasi tutto il codice del programma è stato migrato dal linguaggio C al C++.

Derivato dal codice di Borland InterBase, Firebird viene sviluppato da un'omonima fondazione non profit sponsorizzata da IBPhoenix.

Come si ricorderà, nel febbraio del 2004 Mozilla Foundation decise di rinominare il proprio browser da Firebird a Firefox per evitare l'omonimia con il database open source.

Nel momento in cui si scrive il sito di Firebird risulta irraggiungibile, probabilmente a causa dell'improvviso picco di traffico seguito all'annuncio della nuova release.
59 Commenti alla Notizia Firebird 2, un database open che sfida i big
Ordina
  • Scusate, forse sto andando un po' fuori tema.

    Se a me non interessa una cippa delle prestazioni, ma solo di poter creare un semplice gestionale con qualche modesta maschera di inserimento, cosa mi consigliate?

    A parte Access ovviamente, di cui si può dire peste e corna ma che consente di costruire un'applicazione, comprese maschere e report, in 4 e 4-8.
  • perchè non provi con moduli prestampati e penna?
    non+autenticato
  • > perchè non provi con moduli prestampati e penna?

    Non capisco l'ironia. Newbie, inesperto

  • neppure io, eppure nel mondo sembra sia tanta, e che ci si possa anche fare politica...
    apparte l'ironia appunto, prova con OpenOffice. il wizard non mi sembra male, e se hai dimestichezza con MSoffice ti dovresti trovare abbastanza in linea con access.
    Dagli uno sguardo. alternative per me solo php e sql...
    rb
    non+autenticato
  • Filemaker potrebbe essere un'alternativa. io non lo trovo male
    non+autenticato
  • - Scritto da:
    > Filemaker potrebbe essere un'alternativa. io non
    > lo trovo > male
    Ma non è gratuito, anzi costa abbastanza.
    non+autenticato
  • > apparte l'ironia appunto, prova con OpenOffice.
    > il wizard non mi sembra male, e se hai
    > dimestichezza con MSoffice ti dovresti trovare
    > abbastanza in linea con
    > access.

    L'avevo provato quando era ancora alla 1.0 o 1.1. Ripasserò a vedere come è migliorato con la 2, grazie.

    > Dagli uno sguardo. alternative per me solo php e
    > sql...

    Ecco, ma esiste una versione/add-on di PHPMyAdmin che permette di disegnare delle maschere di inserimento personalizzate? O almeno qualche utility che permetta di farlo senza ricorrere alla programmazione in PHP nuda e cruda?

    Grazie.
    -----------------------------------------------------------
    Modificato dall' autore il 15 novembre 2006 11.07
    -----------------------------------------------------------
  • confrontato a SQL od oracle, le prende di santa ragione?

    non+autenticato
  • La domanda è malposta.
    non+autenticato

  • - Scritto da:
    > La domanda è malposta.

    Forse voleva chiedere che ore sono.
    non+autenticato
  • un programmatore mi fece una applicazione usando delphi + firebird

    ricordo che disse che così era possibile la multiutenza e "altro che con Access"

    boh!!!!!

    che mi dite?
    non+autenticato

  • - Scritto da:
    > un programmatore mi fece una applicazione usando
    > delphi +
    > firebird
    >
    > ricordo che disse che così era possibile la
    > multiutenza e "altro che con
    > Access"
    >

    Beh Firebird è un DBMS "serio", non come Access. Cosa strana, Firebird è uno dei pochi DBMS che supporta la MVCC (Multi-version concurrency control) che, correggetemi se sbaglio, non è supportato nemmeno dalle ultime versioni di Oracle.
    non+autenticato

  • > Cosa strana, Firebird è uno dei pochi DBMS che
    > supporta la MVCC (Multi-version concurrency
    > control)

    L'accoppiata firebird/delphi e fose la più usata avendo l'IDE dei componenti già pronti per l'accesso diretto al DB (anche se certificati solo per Interbase).

    La MVCC è una gran cosa, ma pochi sviluppatori sanno cosa sia. Il risultato è che tengono aperte le transazioni per lunghissimo tempo e fanno lievitare il numero di versioni con una decadenza delle prestazioni mostruosa che ti fanno rimpiangere db3 ...
    Mi è capitato di recente con una piccola riorganizzazione dei movimenti di magazzino:

    1. Metodo classico che usa un programatore che da un db locale e passa a firebird : 3h 48m
    2. Uso intensivo di SQL e Stored Procedures con transazioni apri/chiudi cortissime : 2m 40s

    Chi volesse cimentarsi con questo (e con altri RDMS) meglio che legga della documentazione specifica o andrà incontro a brutte sorprese.

    Con Delphi e Firebird molto meglio usare i componenti FIBPlus che ottimizzano questa modalità di programmazione (la documentazione la spiega) e dimenticarsi l'oggetto TTable e usare solo TQuery.

    non+autenticato

  • - Scritto da:
    >
    >
    >
    > La MVCC è una gran cosa, ma pochi sviluppatori
    > sanno cosa sia. Il risultato è che tengono aperte
    > le transazioni per lunghissimo tempo

    AssolutamenteTriste, le transazioni vanno aperte e chiuse, non lasciate aperte in attesa di input dall'operatoreTriste



    > 2. Uso intensivo di SQL e Stored Procedures con
    > transazioni apri/chiudi cortissime : 2m
    > 40s


    Le stored procedures, in particolare le selectable stored procedures sono potentissime, sto man mano cercando di trasferire logica dall'applicativo alle SPSorride



    >
    > Con Delphi e Firebird molto meglio usare i
    > componenti FIBPlus che ottimizzano questa
    > modalità di programmazione (la documentazione la
    > spiega) e dimenticarsi l'oggetto TTable e usare
    > solo
    > TQuery.
    >

    Le TTable vanno abolite, io uso la classica catena DBX/Midas: TSQLQuery+TDataProvider+TClientDataset (altro strumento potente)
    non+autenticato

  • - Scritto da:

    > La MVCC è una gran cosa, ma pochi sviluppatori
    > sanno cosa sia. Il risultato è che tengono aperte
    > le transazioni per lunghissimo tempo e fanno
    > lievitare il numero di versioni con una decadenza
    > delle prestazioni mostruosa che ti fanno
    > rimpiangere db3

    Non ho capito cosa c'entri MVCC con il fatto di tenere aperte le transazioni. In generale sui db devi effettuare transazioni il più velocemente possibile in modo da diminuire i lock e i conflitti. MVCC serve a fare in modo di poter programmare "male" tanto il sistema risolve il problema.

    Insomma mi sembra che tu abbia invertito i due fattori.

    non+autenticato

  • - Scritto da:
    >
    > - Scritto da:
    >
    >
    > Non ho capito cosa c'entri MVCC con il fatto di
    > tenere aperte le transazioni. In generale sui db
    > devi effettuare transazioni il più velocemente
    > possibile in modo da diminuire i lock e i
    > conflitti. MVCC serve a fare in modo di poter
    > programmare "male" tanto il sistema risolve il
    > problema.
    >
    > Insomma mi sembra che tu abbia invertito i due
    > fattori.
    >

    Sono più legate di quanto pensi.
    Il decadimento delle prestazioni quando tieni maldestramente aperte le transazioni (read/write) per lungo tempo salvando con commitretaining è dovuta al proliferare delle versioni che firebird/interbase crea. Se tieni una transazione read only aperta per lungo tempo non succedede nulla di questo appunto perchè in quasto caso non vengono generate multi versioni aggiuntive dei record. Il proliferare dell'uso delle grid per visualizzare in formato "excel" i dati ti obbliga a delle scelte, ogni volta che tu chiudi la transazione la tua grid si vuota e perdi i puntatori. Il compromesso e usare transazioni di sola lettura per mostrare i dati e apri/chiudi transazioni read/write per salvare i dati.
    Il mio riferimento a FIBPlus era proprio per quasto, dato che automatizzano questo (e altro) meccanismo.

    non+autenticato
  • nze di una persona

    ma voi cosa pensereste di una persona che paragoni una fiat 600 con un aereo di linea

    come minimo che è uno che non capisce niente

    e lo stesso nel tuo caso.

    diffidate delle competenze informatiche di chi fa paragoni
    come il signore sotto


    gente del genere è capace di creare applicazioni che usano DBMS come mysql, sql server ,oracle, in situazioni in cui un database access o equivalenti open sono più che sufficienti, situazioni in cui danno da gestire un dbms a un povero cristo per due mascherine e quattro dati in croce (già capitato già visto da linciare) maaaaaaaa



    - Scritto da:
    >
    > - Scritto da:
    > > un programmatore mi fece una applicazione usando
    > > delphi +
    > > firebird
    > >
    > > ricordo che disse che così era possibile la
    > > multiutenza e "altro che con
    > > Access"
    > >
    >
    > Beh Firebird è un DBMS "serio", non come Access.
    > Cosa strana, Firebird è uno dei pochi DBMS che
    > supporta la MVCC (Multi-version concurrency
    > control) che, correggetemi se sbaglio, non è
    > supportato nemmeno dalle ultime versioni di
    > Oracle.
    non+autenticato
  • > gente del genere è capace di creare applicazioni
    > che usano DBMS come mysql, sql server ,oracle,
    > in situazioni in cui un database access o
    > equivalenti open sono più che sufficienti,

    Occorre valutare caso per caso.
    Ho visto piccole applicazioni, destinate a crescere, sviluppate su db access, che a breve hanno dovuto migrare tutti i dati su sql server.
    Se il progettista avesse avviato il progetto utilizzando subito un sql server si avrebbe evitato la migrazione.

    Solitamente per applicazioni monoutente non si utilizza un sql server ma ci sono, ovviamente, delle eccezzioni.


    > situazioni in cui danno da gestire un dbms a un
    > povero cristo per due mascherine e quattro dati
    > in croce (già capitato già visto da linciare)
    > maaaaaaaa

    Se quel povero cristo sei tu, allora capisco. A bocca aperta
    non+autenticato

  • - Scritto da:

    > Occorre valutare caso per caso.
    > Ho visto piccole applicazioni, destinate a
    > crescere, sviluppate su db access, che a breve
    > hanno dovuto migrare tutti i dati su sql
    > server.

    Una errata previsione può capitare. Certo che Access non è un db per applicazioni ma un db per produttività personale. Da Access a SQL Server è comunque relativamente facile (programmi permettendo).

    > Se il progettista avesse avviato il progetto
    > utilizzando subito un sql server si avrebbe
    > evitato la
    > migrazione.
    >
    > Solitamente per applicazioni monoutente non si
    > utilizza un sql server ma ci sono, ovviamente,
    > delle
    > eccezzioni.

    Se è una applicazione conviene usare uno dei db più piccoli come MSDE o SQL Server Express. Poi all'occorrenza è banale passare ai fratelli maggiori (sempre che il programmatore abbia scritto il codice correttamente tenendo conto di problematiche come multiutenza e transazioni).


    > > situazioni in cui danno da gestire un dbms a un
    > > povero cristo per due mascherine e quattro dati
    > > in croce (già capitato già visto da linciare)

    Sono d'accordo con te. Ma i database piccoli risolvono in parte o del tutto questi problemi. Ad esempio SQL Server Express può essere emmbeddato nelle applicazioni in modo trasparente per l'utente finale.

    non+autenticato
  • ...che è paragonabile a oracle...
    non+autenticato

  • - Scritto da:
    > ...che è paragonabile a oracle...

    mi sa che l'hai fatta fuori dalla tazza eh...
    non+autenticato
  • Dici?
    http://www.janus-software.com/fb_fyracle.html
    guarda chi, nativamente, ci va più vicino... (e lì si parla della versione 1.5 di Firebird).
    saluti
    non+autenticato
  • secondo me questo test rende meglio l'idea dicome vanno:
    http://www.root.cz/clanky/mysql-vs-postgresql-vs-f.../
    non+autenticato
  • il test è molto impietoso, forse con la versione 2 potrebbe migliorare

    Carlo
    non+autenticato

  • > il test è molto impietoso, forse con la versione
    > 2 potrebbe migliorare

    Migliorare ancora? Se i numerini sui test indicano i tempi di esecuzione (come credo) direi che Firebird 1.5 spazzava via gia' tutti...

    M.
    non+autenticato

  • - Scritto da:
    > secondo me questo test rende meglio l'idea dicome
    > vanno:
    > http://www.root.cz/clanky/mysql-vs-postgresql-vs-f
    scusa, sono un po' carente di cecoSorride, cosa dice?
    non+autenticato
  • anche io.. sarabbe solo da capire se i grafici sono i tempi di esecuzione in secondi.
    non+autenticato
  • Non dimentichiamo anche mysql che il suo sporco dovere lo fa tutto

  • - Scritto da: Angelone
    > Non dimentichiamo anche mysql che il suo sporco
    > dovere lo fa
    > tutto

    se uno si accontenta di un dbms zoppo va bene anche access
    non+autenticato

  • - Scritto da:
    >
    > - Scritto da: Angelone
    > > Non dimentichiamo anche mysql che il suo sporco
    > > dovere lo fa
    > > tutto
    >
    > se uno si accontenta di un dbms zoppo va bene
    > anche
    > access

    Mica è zoppo. Ha funzionalità minori! Se hai bisogno di trigger, procedure e performance è ovvio che non usi MySql.
    Se devi realizzare un sitarello a basso costo MySQL decisamente superiore ad Oracle.
    non+autenticato