Firebird SQL: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
Nessun oggetto della modifica |
Nessun oggetto della modifica |
||
Riga 15:
|SitoWeb =
}}
'''Firebird SQL''' è un DB e anche [[RDBMS|database management system relazionale]] (RDBMS), [[open source]] distribuito sotto [[licenza (informatica)|licenza]] IPL ([[Interbase Public License]]) o [[IDPL]] (simile alla [[Mozilla Public License]]).
Line 22 ⟶ 21:
Le principali caratteristiche 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 distribuite 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]].
Nel [[2003]], une querelle<ref>[http://www.mozillazine.org/talkback.html?article=3082 Reports on Phoenix/Minotaur Renaming Focus on Firebird Database Protest]</ref> ha opposto la comunità di [[Mozilla]] e Firebird dopo che un derivato del [[browser]] Mozilla è stato rinominato [[Mozilla Firebird]]. Le due parti si sono alla fine accordate e il navigatore è stato rinominato Mozilla Firefox al suo passaggio nella versione 0.8, iniziata nel [[2004]].<ref>{{cita web |url=http://www.mozilla.org/projects/firefox/firefox-name-faq.html |titolo=Mozilla Firefox - Brand Name Frequently Asked Questions |cognome=Garrity |nome=Steven |coautori=Markham, Gervase; Goodger, Ben; Decrem, Bart; et al. |sito=mozilla.org |editore=Mozilla Foundation |accesso=3 aprile 2011 |urlmorto=sì |urlarchivio=https://web.archive.org/web/20120228204829/http://www.mozilla.org/projects/firefox/firefox-name-faq.html |dataarchivio=28 febbraio 2012 }}</ref>
Line 49 ⟶ 48:
Firebird 3.0 è l'ultima "stable release". Vi è previsto il supporto alle [[stored procedure]] nei linguaggi come [[Java (linguaggio di programmazione)|Java]] e [[C++]], e [[SQL#DML: Manipolazione dei dati|funzioni window SQL]] (SELECT) che restringono i risultati delle query. Una seconda versione alpha era stata distribuita in gennaio 2014.<ref>{{cita web |url=http://www.firebirdsql.org/en/roadmap/|titolo=Firebird Roadmap |data=marzo 2014 }}</ref>. Gli obiettivi principali di questa versione sono l'unificazione delle architetture server e il miglioramento del supporto ai [[Sistema multiprocessore simmetrico|sistemi multiprocessore simmetrico]] (SMP) e ai processori [[multi-core]].<ref>{{collegamento interrotto|1=[http://web.firebirdsql.org/download/prerelease/rlsnotes/Firebird-3.0.0_RC1-ReleaseNotes.pdf ''Release Notes Version 3.0 RC 1''.] |date=marzo 2018 |bot=InternetArchiveBot }} (PDF) firebirdsql.org; accesso il 9 novembre 2015.</ref> La versione 3.0 stabile è uscita il 19 aprile 2016.
== Descrizione ==
== Integrazione in Libre Office ==▼
=== Organizzazione del progetto ===▼
* [[Firebird Foundation]] - Raccoglie fondi, organizza conferenze e ne promuove l'utilizzo▼
* Gruppo di sviluppatori in tutto il mondo▼
▲=== Integrazione in Libre Office ===
Col lavoro del [[Google Summer of Code]] 2013 è cominciata l'integrazione di Firebird come sostituto di [[HSQLDB]] in [[LibreOffice]], nel modulo [[LibreOffice Base|Base]].<ref>{{Cita web|url=http://www.firebirdnews.org/?p=6610|titolo=Firebird Embedded and LibreOffice is the killer combination to scale from a single file application to a client/server approach|data=14 febbraio 2012|autore=mariuz|editore=Firebirdnews.org|accesso=8 luglio 2013}}</ref><ref>{{Cita web|url=http://www.ahunt.org/2013/05/gsoc-2013-libreoffice-firebird-sql-connector/|accesso=8 luglio 2013|titolo=GSOC 2013: LibreOffice Firebird SQL Connector|data=28 maggio 2013|autore=ahunt}}</ref>
Libre Office sino alla versione 5.2 poteva usare Firebird 2.5; dalla release Libre Office 5.3 può essere incorporato Firebird, release 3.0. o successive.
▲== Organizzazione del progetto ==
▲* [[Firebird Foundation]] - Raccoglie fondi, organizza conferenze e ne promuove l'utilizzo
▲* Gruppo di sviluppatori in tutto il mondo
▲== Interfacce grafiche di amministrazione database Firebird ==
Esistono molte interfacce grafiche di amministrazione per creare database con Firebird, con diverse licenze, scaricabili dal sito <ref>{{cita web|https://www.ibphoenix.com/download/tools/admin/|Sito di Ibphoenix|lingua=en}}</ref>
Le principali sono:
Riga 66:
* {{cita web|http://firebirdsql.org/en/third-party-tools/|elenco sul sito Firebird|lingua=en}}
=== Fyracle ===
[[Fyracle]]<ref>[http://www.janus-software.com/fb_fyracle.html Janus Software<!-- Titolo generato automaticamente -->]</ref> è una versione modificata di Firebird SQL che consente il suo utilizzo in sostituzione di [[Oracle Database|Oracle]]. Inoltre la sintassi del linguaggio SQL di Oracle potrà essere utilizzata per effettuare delle query su database Firebird.
Una delle applicazioni più utili di questa versione è quella di permettere l'impiego di Firebird con l'[[Enterprise resource planning|ERP]] [[Compiere]], che è progettato per utilizzare Oracle.
== Caratteristiche
* È conforme allo SQL-92 Entry Level. Si può usare lo standard [[ANSI]] [[SQL]] per scrivere delle [[query]] portabili tra piattaforme diverse. In più Firebird ha delle estensioni che anticipano l'SQL3 come le stored procedure e i trigger e anche altre dell'SQL200X. È possibile accedere contemporaneamente ad un [[database]] Firebird da più applicazioni permettendo a più [[client]] di lavorare con gli stessi dati in conformità al modello [[client/server]].
* Implementa le specifiche [[ACID|A.C.I.D.]]; cioè il concetto di atomicità, consistenza, isolamento e durabilità.
Riga 98:
* 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]].
=== Struttura del database ===▼
== Architetture ==▼
Firebird ha 3 tipi di architetture che lavorano in maniera diversa, ma non per questo una è migliore o peggiore 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.▼
=== Classic Server ===▼
È la prima architettura utilizzata dall'antenato di Firebird, Interbase, tra la fine degli [[anni 1980|anni ottanta]] e [[anni 1990|novanta]], a quel tempo le risorse dei server erano scarse e i programmi richiedevano meno memoria.▼
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 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.▼
Questa architettura è l'unica che supporta [[Multiprocessore simmetrico|SMP]] (la memoria condivisa tra i vari processori) e l'[[Hyper-Threading]] anche se i vantaggi dipendono fortemente dal sistema operativo e dalle caratteristiche tecniche stesse del computer, soprattutto della memoria.▼
Lato client ogni richiesta di un nuovo processo occupa circa 2 MB in RAM.▼
=== Superserver ===▼
Dal 1996 e più precisamente 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 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 notevole 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 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.▼
=== 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 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 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 predefinita è .fdb ma firebird è compatibile anche con database creati precedentemente anche dal suo antenato, Interbase, e quindi file con estensione .gdb
Line 151 ⟶ 121:
Il tipo di dialetto viene salvato nel database e quindi non dipende dal server.
=== Specifiche
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 MiB 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. È evidente che se l'applicazione interagisce in modo intensivo col database il numero di accessi sopraindicato deve essere di conseguenza ridotto.
Line 182 ⟶ 152:
di questi limiti saranno definitivamente ed ampiamente superati.
=== Funzionalità
* Accurata revisione dei meccanismi di indicizzazione per incrementare le prestazioni e minimizzare i colli di bottiglia durante le ricerche e le selezioni.
* Varie limitazioni ereditate dal codice originario sono state rimosse, per es. il limite di 252-byte sulla lunghezza degli indici e il limite di 30Gb sulla dimensione delle tabelle.
Line 195 ⟶ 165:
* Ridefinizione dell'architettura in modalità "serverless" (per connessioni locali) su Windows, per eliminare l'intrinseca instabilità del protocollo IPServer originario.
* Implementazione delle Services API completata su tutte le piattaforme.
▲== Architetture ==
▲Firebird ha 3 tipi di architetture che lavorano in maniera diversa, ma non per questo una è migliore o peggiore 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.
▲=== Classic Server ===
▲È la prima architettura utilizzata dall'antenato di Firebird, Interbase, tra la fine degli [[anni 1980|anni ottanta]] e [[anni 1990|novanta]], a quel tempo le risorse dei server erano scarse e i programmi richiedevano meno memoria.
▲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 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.
▲Questa architettura è l'unica che supporta [[Multiprocessore simmetrico|SMP]] (la memoria condivisa tra i vari processori) e l'[[Hyper-Threading]] anche se i vantaggi dipendono fortemente dal sistema operativo e dalle caratteristiche tecniche stesse del computer, soprattutto della memoria.
▲Lato client ogni richiesta di un nuovo processo occupa circa 2 MB in RAM.
▲=== Superserver ===
▲Dal 1996 e più precisamente 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 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 notevole 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 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.
▲=== 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 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 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.
== Note ==
| |||