Versione delle 12:33, 20 gen 2016 modifica Antonell (discussione \| contributi) 2 441 modifiche mNessun oggetto della modifica ← Differenza precedente		Versione delle 03:21, 21 gen 2016 modifica annulla Bottuzzu (discussione \| contributi) Bot, Esenti dal blocco IP 1 179 265 modifiche m apostrofo tipografico Differenza successiva →
Riga 31: Già quando era un prodotto commerciale e chiuso (prima della versione 6.0) l'antenato di Firebird era molto stimato e vantava una numerosa utenza, tra cui grossi nomi come [[NASA]], National Bank di Chicago, [[Nokia]], [[Ericsson]], [[Boeing]], Boston Stock Exchange e molti altri.{{citazione necessaria}} La bassa occupazione di memoria, sia [[RAM]] che su disco (richiede ancora oggi poco più di 4 [[megabyte\|MB]] di RAM e meno di 10 MB su disco per una completa installazione), la facilità ~~d’installazione~~d'installazione, ~~d’utilizzo~~d'utilizzo e di gestione erano (e sono) molto competitivi verso altri RDBMS con uguali ed anche inferiori qualità e funzionalità. InterBase, dal principio, fu concepito, progettato e realizzato per ~~un’utenza~~un'utenza professionale ed aziendale pagante, con tutte le implicazioni del caso. InterBase fu sviluppato (nell'ultima fase della sua vita) da un'azienda leader a livello mondiale nello sviluppo di software per programmatori professionisti: la [[Borland\|Borland International]]. La prima versione di Firebird fu null'altro che un InterBase riveduto e migliorato dopo che la Borland l'aveva reso opensource (la pubblicazione del codice sorgente di Interbase 6.0 avvenuta il 25 luglio 2000).<ref>{{cita news\| titolo=Inprise/Borland Introduces InterBase 6.0 Now Free and Open Source on Linux, Windows, and Solaris \| data=16 luglio 2000 \| url=http://www.borland.com/news/press_releases/2000/07_16_00_ib6.html \| urlarchivio = http://web.archive.org/web/20041206174134/www.borland.com/news/press_releases/2000/07_16_00_ib6.html \| dataarchivio = 6 dicembre 2004 \| accesso=29 gennaio 2009}}</ref><ref>{{cita web \|url=http://www.linuxtoday.com/news_story.php3?ltsn=2000-07-25-004-06-PR-SV-SW \|titolo=Borland.com: Inprise/Borland Introduces Interbase 6.0 Now Free and Open Source on Linux \|accesso=29 gennaio 2009 \|editore=Linux Today}}</ref> Firebird 1.0 infatti non rappresenta una rivoluzione rispetto ad InterBase 6.0, ma elimina alcuni seri problemi di sicurezza e qualche bug con ~~l’aggiunta~~l'aggiunta di poche migliorie. Firebird 1.5, pur essendo una versione di transizione verso la nuova 2.0, rappresenta un notevole passo avanti rispetto alla versione precedente. L'intero motore del database server è stato riscritto in [[C++]], mentre la Riga 56: == Organizzazione del progetto == * [[Firebird Foundation]] - Raccoglie fondi, organizza conferenze e ne promuove ~~l’utilizzo~~l'utilizzo * Gruppo di sviluppatori in tutto il mondo Riga 75: * Tre architetture diverse a seconda del tipo della macchina e di come si vuole utilizzare il [[DBMS]]. * ''OSD'' (On-Disk Structure) 10.1 per Firebird 1.5 e OSD 11 per Firebird 2.0 * Ottimizzazione delle [[query]] a livello di server o manualmente ~~dall’utente~~dall'utente. Quando viene scritto del codice SQL, Firebird, prima di eseguirlo, cerca di ottimizzarlo grazie al suo optimizer interno. * [[Vista (basi di dati)\|Viste]] aggiornabili in seguito ad eventi stabiliti. * [[Stored procedure]]. Sono delle applicazioni SQL che vengono memorizzate all'interno del database e vengono eseguite a livello di server. Offrono una grande flessibilità e potenza per svolgere i compiti più impensabili e bilanciare il carico di lavoro tra il client ed il server. Riga 82: * Gestione del [[Tipo di dato (basi di dati)\|tipo di dato]] [[Binary large object\|BLOB]] con possibilità di memorizzare dati di qualsiasi genere (immagini, suoni, animazioni, testi…). * Messaggi di allerta che informano un'applicazione delle modifiche avvenute nel database ed in seguito alle quali l'applicazione è chiamata a svolgere delle specifiche azioni. * ''UDF'' (User Defined Functions), ossia, funzioni definite ~~dall’utente~~dall'utente che permettono di scrivere programmi esterni che possono essere eseguite da codice SQL dall'interno del database. * Collegamento tra diverse relazioni con possibilità di eseguire su di esse delle query anche molto complesse. La lettura dei dati non è bloccante. Tutti i client possono leggere contemporaneamente gli stessi record. * Possibilità di richiamare le [[Application programming interface\|API]] di Firebird tramite codice SQL/DSQL (Dynamic SQL) in modo del tutto trasparente. * Possibilità di gestione di Firebird tramite l'applicazione grafica windows IBOConsole. Sono garantite l'esecuzione delle query e le operazioni di backup, restore, manutenzione e gestione della sicurezza. * ''isql'', ossia Interactive SQL, è un'applicazione a riga di comando, multipiattaforma e serve per una totale gestione di Firebird. * ''gpre'', è un preprocessore per convertire codice embedded SQL/DSQL in formati leggibili da linguaggi esterni. Ciò ci permette di scrivere applicazioni esterne in altri linguaggi, in [[C (linguaggio)\|C]] in modo particolare, all'interno delle quali possiamo inserire del codice SQL. In questo modo possiamo ottenere ~~un’elevata~~un'elevata efficienza ed aggiungere alle nostre applicazioni qualsiasi altra funzionalità. * Database di sola lettura. È possibile rendere un database accessibile solo per la lettura da impedire eventuali modifiche ai dati. Questa caratteristica è molto utile quando si distribuiscono programmi in CD-ROM con la versione embedded di Firebird. * Oltre a queste caratteristiche native di Firebird ce ne sono altre realizzate grazie al contributo di programmi esterni che permettono a Firebird di avere altre significativi vantaggi ad esempio la ricerca full text, la possibilità di gestire la replica oppure il salvataggio dei database automatica, e il supporto per il [[clustering]]. == Architetture == Firebird ha 3 tipi di architetture che lavorano in maniera diversa, ma non per questo una è migliore o peggiore ~~dell’altra~~dell'altra. Il motivo di questa differenziazione è stata la diversità di sistemi operativi, di risorse hardware e anche di possibili utilizzi del database. Tutti questi fattori permettono di scegliere di volta in volta quella più adatta. Riga 99: Questa architettura è usata ancora oggi per i sistemi operativi che hanno una gestione molto limitata dei thread. (Negli altri viene usata la versione SuperServer). In pratica per ogni connessione client, Firebird, apre sul server un processo dedicato con una memoria dedicata dove far elaborare le richieste del client, la cache di ogni processo non viene vista dagli altri (questo non permette lo scambio di informazioni già lette tra i vari processi). Normalmente la cache di ogni processo è per default di 75 pagine. In questa maniera si utilizzano più processi a seconda delle connessioni dei client, questa architettura è indicata nel caso il nostro server abbia più microprocessori, infatti ogni microprocessore si prenderà carico di uno o più processi (Firebird permette ~~un’uguale~~un'uguale distribuzione fra le varie CPU dei processi sia a seconda del numero sia a seconda della grandezza). Questa architettura rimane la migliore opzione nei casi dove c'è bisogno di alte performance e le risorse del sistema sono adeguate ad aumentare in maniera proporzionale alle richieste di nuove connessioni da parte dei client, ad esempio nel caso non ci siano connessioni sul server, non viene utilizzata per niente la memoria. Questa architettura è ideale, soprattutto, per i sistemi che si basano su elaborazioni complesse dove c'è poco input interattivo da parte degli utenti. Normalmente viene utilizzata con sistemi operativi GNU/Linux e Unix, mentre per Microsoft esiste una specifica versione di Firebird ma viene sconsigliata soprattutto in presenza di più processori. Riga 106: === Superserver === Dal 1996 e più precisamente ~~dall’uscita~~dall'uscita di Interbase 4.1, fu introdotta l'architettura Superserver. Questa architettura andava incontro alle nuove caratteristiche tecniche di Windows, più precisamente all'architettura a 32 bit utilizzata per la prima volta con Windows 95. Il vantaggio della versione Superserver è che si possono utilizzare i thread e allocare dinamicamente memoria cache condivisa dove poter andare a leggere le informazioni in comune; i thread possono girare ~~all’interno~~all'interno di un singolo processo o più processi. La memoria condivisa (cache) per questo tipo di architettura è per default di 2.048 pagine. Questa caratteristica è sicuramente un grosso vantaggio rispetto alla versione Classic server dove ogni processo ha un proprio spazio di memoria specifico e non condiviso. Questa proprietà rende indicata la versione Superserver, soprattutto, sia nei casi di un numero di operazioni interattive di scrittura e lettura molto elevate sia anche dove le risorse del computer sono limitate. Infatti avendo una memoria condivisa, tra i vari thread, c'è meno spreco di RAM. Normalmente ~~all’avvio~~all'avvio di Firebird la versione superserver anche se non c'è nessuna connessione con i client occupa (a differenza della versione classic server) un po' di memoria per mettersi in ascolto delle richieste, circa 2 MB. Da Firebird 1.0. la versione superserver è disponibile anche per altri sistemi operativi come GNU/Linux. Questa architettura è quella consigliata per i sistemi Microsoft dove la versione classic server per adesso è solo a livello "sperimentale", non ancora affidabile. Riga 118: === Embedded server === È l'ultima nata come architettura, sviluppata dalla versione 1.5 di Firebird in poi. Questo modello non è altro che una versione compatta ~~dell’architettura~~dell'architettura Superserver, diciamo compatta perché non è altro che una libreria (''fbembedd.dll'') che fa il lavoro sia come parte server che client. Naturalmente permette la gestione del database solo a livello locale. Questo significa che questa architettura non si mette in ascolto di richieste di altri client ma soddisfa solo operazioni locali. Questo discorso vale anche per quei server utilizzati come terminal server, questa architettura permette ~~l’utilizzo~~l'utilizzo di una sola connessione per volta. Normalmente questa architettura viene utilizzata per quei database che girano su un solo PC, come ad esempio i portatili oppure per un database in sola lettura ad esempio su [[CD-ROM]]. Le risorse richieste da questa architettura sono minime, e può pertanto essere installata su qualsiasi client. L'interfaccia per la gestione del DBMS è identica a quella della versione SuperServer. == Struttura del database == Il database utilizzato da Firebird è normalmente un file con estensione .fdb, Tuttavia il database può essere suddivido anche in più file (sempre .fdb) con una dimensione precisa. Questo è stato fatto per risolvere il limite strutturale di certi sistemi operativi che non possono gestire file più grandi di una certa dimensione. ~~L’estensione~~L'estensione predefinita è .fdb ma firebird è compatibile anche con database creati precedentemente anche dal suo antenato, Interbase, e quindi file con estensione .gdb Il database essendo contenuto normalmente in un file ha il vantaggio di essere portato da un pc ~~all’altro~~all'altro, anche con sistemi operativi diversi, in maniera molto veloce e senza bisogno di particolari meccanismi per essere ripristinato. Può essere portato anche con un semplice copia-incolla oppure comprimendo e decomprimendo il file. Queste due operazioni però vengono sconsigliate perché non controllano se il db è corrotto anzi potrebbero peggiorare la situazione. Per quanto riguarda il backup/restore esiste ~~un’eseguibile~~un'eseguibile dedicato (gbak) che sarà descritto in dettaglio in seguito. Il programma di backup ha numerose funzionalità: chiudere le transazioni aperte, controllare e riparare nei casi che il db sia corrotto, ricreare gli indici ed eliminare record obsoleti creati dalla architettura multigenerazionale (che vedremo successivamente). La O.S.D. (structure on disk) del database è cambiata dalla 10.0 di firebird 1.0. alla 10.1 di firebird 1.5 fino ad arrivare alla 11.0 di firebird 2.0. Naturalmente Firebird 2.0. può leggere qualsiasi struttura di database precedente alla 11.0, infatti nel momento che viene aperto viene in automatico convertito alla 11.0. (è sempre comunque consigliato utilizzare Gbak per far cambiare la struttura al db, in questa maniera viene fatto anche un controllo di errori del database). Sempre parlando del discorso della compatibilità con le vecchie versioni bisogna spiegare anche ~~l’argomento~~l'argomento dei cosiddetti "dialetti di Firebird". === Dialetti di Firebird === La prima versione di Firebird (Firebird 1.0) aveva introdotto diverse novità che hanno avuto come conseguenza ~~l’alterazione~~l'alterazione di alcuni meccanismi interni del motore del database. Quindi, bisognava introdurre qualche artificio per poter ancora utilizzare vecchi database ed applicazioni create con le precedenti versioni. La soluzione è stata ~~nell’introduzione~~nell'introduzione dei dialetti che hanno il compito di controllare ~~l’appartenenza~~l'appartenenza o meno di una estensione ad una determinata versione. * Dialetto 1: corrisponde alle notazioni e funzionalità della versione precedente InterBase 5.6. * Dialetto 2: serve solo nel caso di debugging; viene segnalato un errore nel caso in cui viene usata una funzione oppure un comando con implementazione diversa da quella precedente. Per esempio, la variabile DATE nella nuova versione è di tipo diverso da quella della precedente. * Dialetto 3: rappresenta le nuove funzionalità e le estensioni relative solo ~~all’ultima~~all'ultima versione (ad esempio una nuova funzione Timestamp, possibilità di usare contatori a 64 bit e anche tools particolari come la possibilità di replicare il database) e si avvicina di più allo standard ANSI SQL. Il tipo di dialetto viene salvato nel database e quindi non dipende dal server. Riga 164: :La dimensione massima di un segmento per il campo BLOB è di 32 KB. * Numero max. di tabelle collegate con JOIN. Da progetto, non esiste nessun limite a tale valore. Il carico di lavoro del sistema cresce in maniera esponenziale al crescere del numero delle tabelle da collegare con JOIN. Non è consigliabile superare il numero di 16 tabelle in una singola query. * Numero max. di query annidate. Non esiste un limite stabilito da progetto perché dipende strettamente dalla complessità delle query e dal risultato che ~~l’utente~~l'utente vuole ottenere. * Numero max. di colonne per un indice composito: 16. * Numero max. di stored procedure e trigger annidati: 750 per tutti i sistemi Windows e 1000 per i sistemi Unix. Riga 172: limitazioni sono prevalentemente delle conseguenze dei sistemi operativi utilizzati. Con la diffusione di sistemi operativi a 64 bit e con l'annunciata versione di Firebird per tali sistemi, versione già esistente con ~~l’avvento~~l'avvento di Firebird 2.0 che può girare su sistemi a 64 bit) molti di questi limiti saranno definitivamente ed ampiamente superati.

Firebird SQL: differenze tra le versioni