Firebird SQL: differenze tra le versioni

Contenuto cancellato Contenuto aggiunto
appena appena una spolveratina...
altra spolveratina
Riga 9:
sistema_operativo = [[Multipiattaforma]] |
genere = [[RDBMS]] |
licenza = [[Interbase Public License|IPL]] |
sito_web = http://www.firebirdsql.org/
}}
'''Firebird SQL''' è un [[RDBMS|relational database management system relazionale]] (RDBMS) [[opensource]] distribuito sotto licenza IPL ([[Interbase Public License]]).
 
Supporta numerosi [[sistema operativo|sistemi operativi]] tra i quali: [[Windows]], [[FreeBSD]], [[Mac OS X]], [[Linux]] e alcuni sistemi [[Unix]].
*[[Windows]],
*[[FreeBSD]],
*[[Mac OS X]],
*[[Linux]]
*Sistemi [[Unix]].
 
Le principali caratteristiche di questo RDBMS sono l’alto livello di conformità con gli standard [[SQL]], la completa integrazione con molti [[linguaggi di programmazione]] e la facile installazione e manutenzione del software.
 
Le ultime versioni rilasciate portano grandi miglioramenti riguardo alla resistenza del [[software]] ai crash esterni, la velocità d'esecuzione dei comandi SQL e la gestione e l'accesso ai dati del computer.
Tutte queste caratteristiche sono state migliorate prendendo come punto di partenza la precedente versione di Firebird, [[Interbase]] (Firebird è nato dalla pubblicazione del codice sorgente d’Interbasedi Interbase 6.0 avvenuta nel [[2000]]).
Infine Firebird è un software [[open source|Opensourceopensource]] regolato dalla [[Mozilla Public License|Mozilla Public License v. 1.1]] e che quindi può essere usato gratuitamente sia per uso privato sia per applicazioni commerciali.
Firebird è completamente privo di registrazione, licenza o donazioni per la distribuzione su scala e download. Può essere distribuito liberamente per l'utilizzo con qualsiasi software di terze parti, siano esse commerciali o no.
 
==Storia==
Firebird nasce dal codice sorgente di Interbase 6.0 equindi ne acquista tutte le sue caratteristiche principali. E’ più facile capire, quindi, il motivo per cui scegliere Firebird se prima parliamo del motivo per cui una volta si sceglieva Interbase (il suo antenato).
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 e grossi nomi come la NASA, la National Bank di
Chicago, [[Nokia]], [[Ericsson]], [[Boeing]], Boston Stock Exchange e molti altri.
La bassa occupazione di memoria, sia [[RAM]] che su disco (richiede ancora oggi poco più di 4 MB
di RAM e meno di 10 MB su disco per una completa installazione), la facilità d’installazione,
d’utilizzo e di gestione sono di gran lunga più a portata di mano di molti altri RDBMS con
Line 42 ⟶ 37:
limitato che, dopo tanti anni, ha raggiunto il successo.
InterBase è stato sviluppato da un’azienda seria e leader a livello mondiale nello sviluppo di
software per programmatori professionisti, la [[Borland]] International..
Firebird è null’altro che un InterBase riveduto, migliorato e reso freeware ed opensource.
Firebird 1.0 non ha rappresentato una rivoluzione rispetto ad InterBase 6.0; infatti, ha solo
Line 71 ⟶ 66:
*25/07/2000 Borland rilascia sotto licenza open "Initial Developer’s Public License (IDPL)" Interbase 6.0.
*31/07/2000 Nasce il Progetto Firebird
*22/11/2000 Primo Kitkit d’installazione per Firebird
*14/11/2001 Firebird 1.0.
*23/02/2004 Firebird 1.5 scritto in C++
*13/02/2004 Firebird 1.5.1
*10/11/2004 Firebird 2.0 Alpha
*19/05/2006 Firebird 2.0. Release Candidate 2
 
===Organizzazione del progetto===
'''CHI STA DIETRO A FIREBIRD'''
*[[Jim Starkey]] - Creatore della prima versione e massimo esperto in Firebird
*[[Firebird Foundation]] - Raccoglie fondi, organizza conferenze e ne promuove l’utilizzo
*[[IBPhoenix]] - Software house tools per DBA
*Gruppo di sviluppatori in tutto il mondo
 
'''CHI LO USA'''
*Motorola
*Nokia
*Boeing
*Boston Stock Exchange
*Nasa
==Caratteristiche tecniche==
Line 98 ⟶ 86:
*Supporta le transazioni. Una funzionalità indispensabile per garantire la correttezza e il buo esito di operazioni di inserimento, aggiornamento o cancellazione di dati.
*Gestione dei lock a livello del singolo record anziché dell’intera pagina. In questo modo gli altri record sono manipolabili liberamente da altri client.
*Supporta il protocollo di rete TCP/IP su tutte le piattaforme garantendo l’utilizzo di Firebird come SQL server sia nelle applicazioni client/server sia in quelle web con completa trasparenza.
completa trasparenza.
*Protocollo XNET usato per accedere ai dati in maniere locale.
*Tre archittetture diverse a seconda del tipo della macchina e di come si vuole utilizzare il DBMS.
Line 105 ⟶ 92:
*Ottimizzazione delle query a livello di server o manualmente dall’utente. Quando viene scritto del codice SQL, Firebird, prima di eseguirlo, cerca di ottimizzarlo grazie al suo optimizer interno.
*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.
*Trigger. Sono simili alle stored procedure ma non vengono mai eseguiti esplicitamente; svolgono le loro azioni in seguito a modifiche apportate alle tabelle (inserimento, modifica o eliminazione di un dato). Sono utili quando si cerca di ottenere un determinato risultato in seguito ad una azione specifica.
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.
*Trigger. Sono simili alle stored procedure ma non vengono mai eseguiti esplicitamente;
svolgono le loro azioni in seguito a modifiche apportate alle tabelle (inserimento, modifica o eliminazione di un dato). Sono utili quando si cerca di ottenere un determinato risultato in seguito ad una azione specifica.
*Un’applicazione può accedere contemporaneamente a più database.
*Gestione del tipo di dato BLOB con possibilità di memorizzare dati di qualsiasi genere (immagini, suoni, animazioni, testi...).
(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 che permettono di scrivere programmi esterni che possono essere eseguite da codice SQL dall’interno del database.
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 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 linea 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 in modo particolare, all’interno delle quali possiamo inserire del codice SQL. In questo modo possiamo ottenere un’elevata efficienza ed aggiungere alle nostre applicazioni qualsiasi altra funzionalità.
*Database di sola lettura. E’ 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.
da linguaggi esterni. Ciò ci permette di scrivere applicazioni esterne in altri linguaggi, in C in modo particolare, all’interno delle quali possiamo inserire del codice SQL. In questo
modo possiamo ottenere un’elevata efficienza ed aggiungere alle nostre applicazioni qualsiasi
altra funzionalità.
*Database di sola lettura. E’ 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.
 
Line 185 ⟶ 163:
==Spefiche di Firebird==
Questa sezione illustra i limiti strutturali di Firebird (molti di essi sono dovuti all'[[hardware]] e al [[sistema operativo]] usato):
*Massimo numero di client connessi al server. Il numero di client che possono contemporaneamente collegarsi al server è teoricamente illimitato. Ma è ovvio che tale numero dipende strettamente dal sistema operativo e dall’ hardware in uso. In linea di massima, un server basato su un Pentium 150 MHZ e 64 MB di RAM potrebbe reggere comodamente l’accesso contemporaneo di 150 client. Queste considerazioni si riferiscono ad un’applicazione client media che esegue delle normali query sul database. E’ evidente che se l’applicazione interagisce in modo intensivo col database il numero di accessi sopraindicato deve essere di conseguenza ridotto.
*Massimo numero di client connessi al server. Il numero di client che possono
*Dimensione massima di un database. La massima dimensione consentita ad un database è 2GB sui sistemi operativi Windows 95/98 e di 4 GB sui sistemi Windows NT/2000 ed alcuni sistemi Unix. Occorre documentarsi sul sistema operativo in uso e controllare la dimensione massima di un file che tale sistema può gestire. Comunque, Firebird permette di suddividere un singolo database in più file e quindi sarà possibile gestire un database che abbia una dimensione limitata solo dalla capienza fisica dell’ hard disk.
contemporaneamente collegarsi al server è teoricamente illimitato. Ma è ovvio che tale
*Numero massimo di file per un database. Da progetto, il numero massimo di file che costituiscono un database Firebird è fissato a 65636 (2*16) perché i file vengono identificati da un intero a 16 bit. Comunque la maggior parte dei sistemi operativi attuali non supporta un numero così elevato di file aperti. Anzi, il numero reale di file mantenuti contemporaneamente aperti è molto minore di 65536. Conviene comunque documentarsi sul sistema operativo in uso e sul numero massimo di file mantenuti aperti contemporaneamente dal sistema e cercare di aumentare quel valore in maniera da rispondere alle vostre esigenze.
numero dipende strettamente dal sistema operativo e dall’ hardware in uso. In linea di
*Numero massimo di tabelle in un database. Anche il numero delle tabelle in un singolo database è stato fissato da progetto a 65536 (2**16) perché il numero delle tabelle viene identificato da un intero a 16 bit.
massima, un server basato su un Pentium 150 MHZ e 64 MB di RAM potrebbe reggere
*Dimensione massima di una linea. E’ stata fissata a 64 KB. Ogni campo BLOB o array contribuisce con 8 byte a questo valore. Le tabelle di sistema (tabelle mantenute automaticamente dal motore database per contenere i propri dati) hanno il limite di 128 KB per linea.
comodamente l’accesso contemporaneo di 150 client. Queste considerazioni si riferiscono ad
*Numero massimo di linee e di colonne per tabella. Da progetto il numero delle linee è fissato a 4.294.967.296. Questo è dovuto al fatto che il numero di una linea viene identificato da un intero a 32 bit. Il numero delle colonne dipende strettamente dal numero delle linee. Una linea potrebbe essere di 64 KB al massimo. Si possono definire in questo caso 16384 colonne di interi (4 byte ciascuno) per costituire una singola tabella di dimensione massima.
un’applicazione client media che esegue delle normali query sul database. E’ evidente che se
*Numero massimo di indici per database. Anche questo numero è stato fissato da progetto a 65536 perché gli indici di un database vengono identificati da un intero a 16 bit.
l’applicazione interagisce in modo intensivo col database il numero di accessi sopraindicato
*Numero massimo di indici per tabella. Questo numero è stato fissato da progetto a 256. In Interbase al massimo erano 64 indici per tabella.
deve essere di conseguenza ridotto.
*Dimensione massima di una chiave indice. Una regola pratica per determinare questo valore è la seguente: iniziare con 256 byte per una chiave per una singola colonna e con 200 byte per una chiave per più colonne e sottrarre 4 byte per ogni colonna aggiuntiva. Esempio: una chiave CHAR per una singola colonna può occupare 256 - 4 = 252 byte; la stessa chiave per 3 colonne occuperà 188 byte. E’ da sottolineare che nel conteggio occorre tenere in considerazione il numero effettivo di byte e non di caratteri.
*Dimensione massima di un database. La massima dimensione consentita ad un database è
*Numero massimo di eventi per una stored procedure: Il programma di Firebord non ha stabilito un limito per queste azioni, ma bisogna controllare le dimensioni di una stored procedure e il trigger.
2GB sui sistemi operativi Windows 95/98 e di 4 GB sui sistemi Windows NT/2000 ed
*Dimensione massima di stored procedure e di trigger: Il limite stabilito è di 48 KB per l'BLR(codice compilato bytecode di una stored procedure o un trigger).
alcuni sistemi Unix. Occorre documentarsi sul sistema operativo in uso e controllare la
*Dimensione max. di un campo BLOB . La dimensione massima di un filecampo cheBLOB taledipende sistemadalla puòdimensione gestire.di pagina del database:
**dimensione pagina = 1 KB - 64 MB per il campo BLOB
Comunque, Firebird permette di suddividere un singolo database in più file e quindi sarà possibile
**dimensione pagina = 2 KB - 512 MB per il campo BLOB
gestire un database che abbia una dimensione limitata solo dalla capienza fisica dell’ hard disk.
**dimensione pagina = 4 KB - 4 GB per il campo BLOB
*Numero massimo di file per un database. Da progetto, il numero massimo di file che
**dimensione pagina = 8 KB - 32 GB per il campo BLOB
costituiscono un database Firebird è fissato a 65636 (2*16) perché i file vengono
:La dimensione massima di un segmento per il campo BLOB è di 32 KB.
identificati da un intero a 16 bit. Comunque la maggior parte dei sistemi operativi attuali
*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.
non supporta un numero così elevato di file aperti. Anzi, il numero reale di file mantenuti
*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 vuole ottenere.
contemporaneamente aperti è molto minore di 65536. Conviene comunque documentarsi sul
sistema operativo in uso e sul numero massimo di file mantenuti aperti
contemporaneamente dal sistema e cercare di aumentare quel valore in maniera da
rispondere alle vostre esigenze.
*Numero massimo di tabelle in un database. Anche il numero delle tabelle in un singolo
database è stato fissato da progetto a 65536 (2**16) perché il numero delle tabelle viene
identificato da un intero a 16 bit.
*Dimensione massima di una linea. E’ stata fissata a 64 KB. Ogni campo BLOB o array
contribuisce con 8 byte a questo valore. Le tabelle di sistema (tabelle mantenute
automaticamente dal motore database per contenere i propri dati) hanno il limite di 128
KB per linea.
*Numero massimo di linee e di colonne per tabella. Da progetto il numero delle linee è
fissato a 4.294.967.296. Questo è dovuto al fatto che il numero di una linea viene identificato
da un intero a 32 bit. Il numero delle colonne dipende strettamente dal numero delle linee.
Una linea potrebbe essere di 64 KB al massimo. Si possono definire in questo caso 16384
colonne di interi (4 byte ciascuno) per costituire una singola tabella di dimensione massima.
*Numero massimo di indici per database. Anche questo numero è stato fissato da progetto a
65536 perché gli indici di un database vengono identificati da un intero a 16 bit.
*Numero massimo di indici per tabella. Questo numero è stato fissato da progetto a 256.
In Interbase al massimo erano 64 indici per tabella.
*Dimensione massima di una chiave indice. Una regola pratica per determinare questo valore
è la seguente: iniziare con 256 byte per una chiave per una singola colonna e con 200 byte
per una chiave per più colonne e sottrarre 4 byte per ogni colonna aggiuntiva. Esempio:
una chiave CHAR per una singola colonna può occupare 256 - 4 = 252 byte; la stessa chiave
per 3 colonne occuperà 188 byte. E’ da sottolineare che nel conteggio occorre tenere in
considerazione il numero effettivo di byte e non di caratteri.
*Numero massimo di eventi per una stored procedure:
##Il programma di Firebord non ha stabilito un limito per queste azioni, ma bisogna controllare le dimensioni di una stored procedure e il trigger.
*Dimensione massima di stored procedure e di trigger:
## Il limite stabilito è di 48 KB per l'BLR(codice compilato bytecode di una stored procedure o un trigger).
*Dimensione max. di un campo BLOB . La dimensione massima di un campo BLOB
dipende dalla dimensione di pagina del database:
##dimensione pagina = 1 KB - 64 MB per il campo BLOB
##dimensione pagina = 2 KB - 512 MB per il campo BLOB
##dimensione pagina = 4 KB - 4 GB per il campo BLOB
##dimensione pagina = 8 KB - 32 GB per il campo BLOB
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 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.
1000 per i sistemi Unix.
*Dimensione max. di una chiave in operazione di SORT. 32 KB.
*Limite di una data. Una data deve variare tra 1 gennaio 100 d.c. e il 29 febbraio 32768 d.c.