Le FAQ di it.comp.software.database

Io ho cercato di dare tutte le notizie giuste, nel caso di link a siti vari, ovviamente il sito puo' essere down, morto o quant'altro, in questo caso mandatemi una mail e correggero' la cosa.

Davide Bianchi ( davidebianchi@davidebianchi.net).

Umberto Masotti (mimmomas@tin.it) che ha fornito informazioni su Interbase, Oscar Manfredini (Oscarman@libero.it) e Michele Giordano (michele.giordano@fastwebnet.it) che hanno fatto tanti commenti, Davide Infantino (dinfantino@expertsystem.it) ha inviato i link relativi a molti database di cui manco sospettavo l'esistenza ed ha scritto alcune note su di essi, Fabio Serra (faser@faser.net) per i commenti su PostgreSQL, Pervasive, Tamino ed i link ai vari "designers", Carlo Vaccari (vaccari@istat.it) che ha fornito le info su Informix, link ed altri commenti, Andrea Palazzi (andrea.palazzi@gmail.com) per le informazioni su IBM Assistant, Maury2ma (maury2ma@libero.it) che ha fornito le informazioni su FileMaker, Lawrence Oluyede (l.oluyede@virgilio.it) che ha fornito le informazioni su Ocelot, Francesco Lamonica (f.lamonica@tin.it) che ha fornito le informazioni su DIA, Stefano Reksten (sreksten@sdb.it) che ha fornito le news su PostgreSQL. Fibia "Sakamoto" FBI ( fibiafbi@vbsimple.net) che ha mandato un po' di correzioni varie, ringo (ringo@tiscali.it) che ha inviato i riferimenti per esportare le tabelle da Access a MySQL.
Lucio Pitocco ha inviato il link per le regole di Codd ed il link per i database Object Oriented. Andrea Raimondi per le info su Firebird, Manlio Perillo ha fornito le info riguardo SQLite.

1. Dove trovo una guida/manuale per il tal database ?
2. Posso installare il tal database su WinXX ?
3. Dove trovo informazioni sull'SQL ?
4. Quali database esistono/quale e' il migliore ?
5. Dove trovo i driver per il tal database ?
6. Quali programmi esistono per il design di un database ?
7. Devo trasportare la mia applicazione dal database X al database Y...
8. Ho mandato un messaggio al gruppo, perche' nessuno mi risponde ?
9. Devo visualizzare i dati estratti dal mio database sul mio sito Web, come faccio a mostrarli a gruppi di X alla volta?
10. Sto' cercando un manuale su...(piccolo elenco di manuali utili)
11. Devo esportare un mucchio di tabelle da Access a MySQL, come faccio?
12. Che cavolo vuol dire ..... ? (glossario)

Per i principali database potete riferirvi a questi siti:

Oracle: http://technet.oracle.com (bisogna registrarsi, ma e' gratuito)
Microsoft SQL Server: http://msdn.microsoft.com/sqlserver/
Microsoft Access: http://msdn.microsoft.com/office/
MySQL: http://www.mysql.com
PostgreSQL: http://www.postgresql.org
Sybase: http://www.sybase.com/sdn/

Alcune "riviste" on-line su SQL Server:
Professional Association for SQL Server - http://www.sqlpass.org
SQL Server Magazine - http://www.sqlmag.com

Altre informazioni "generiche" sui database le trovate su
http://guide.supereva.it/database/ e http://www.dia.uniroma3.it/~atzeni/ .

Su http://gpoulose.home.att.net/ trovate un client generico per Windows, che e' in grado di collegarsi a qualunque database tramite ADO o ODBC.

Davide Infantino ha segnalato il seguente tool: http://www.developercentral.org/sqldump/index.html per fare il dump di un database Microsoft SQL Server (ma non dovrebbero esserci le utility gia' comprese in SQL Server ??).

Domenico Licciardiello segnala WinSQL (http://www.synametrics.com), la versione professional permette l'estrazione dello schema ER, l'esportazione del risultato di una query verso un altro file o (meglio) versi un altro DB, si interfaccia praticamente con tutto anche Paradox (ma esiste ancora?), la versione Lite e' free mentre le altre sono a pagamento con un 'trial' di 30 gg.

TODO: aggiungere qualche altro link

Su questo sito trovate una comparativa tra i vari database, purtroppo il server funziona un po' a singhiozzo http://user.7host.com/papero

Una eccezione lampante a questo e' MySQL che puo' funzionare tranquillamente anche su Win 9X.

In ogni caso, riferirsi _SEMPRE_ alla documentazione del database che si vuole installare dove c'e' scritto quale e' la piattaforma minima sia hardware che software.

Teniamo poi presente che ogni database ha il suo "dialetto", quindi la cosa migliore e' sempre di riferirsi alla documentazione del proprio database.

Su questo sito trovate una comparativa tra i vari database, purtroppo il server funziona un po' a singhiozzo http://user.7host.com/papero..

Questa e' una breve carrellata [grazie a tutti per i commenti, le descrizioni ed i link], di ogni database viene data una breve descrizione e come "scala", cioe' come si adatta a grossi o piccoli volumi di dati, tenere conto che queste informazioni sono per lo piu' derivate da esperienza diretta di utilizzo.

Database "file-based", ovvero basati su uno (o piu') file binari che contengono i dati e su una (o piu') librerie di accesso. Non sono database "server", quindi dotati di una intelligenza, non supportano Stored Procedure, Triggers et similia, in genere non supportano l'SQL o lo supportano in modo molto grezzo, ma per molte applicazioni stand-alone sono ottimi.

Come scalabilita', bisogna considerare questo tipo di database come ottimali su volumi di dati piccoli (<=100.000 records per tabella) ed in generale su applicazioni monoutente, se si va' verso volumi di dati medi (tra 100.000 e 1.000.000 di record) o su un'utilizzo in rete locale con piu' utenti, e' meglio pensare ad un database server.

• BTrieve/Pervasive - http://www.pervasive.com/support/where_btrieve.asp
  Originalmente sviluppato da BTrieve Software venne acquistato poi da Novell che ne fece il suo database di riferimento, includendo nel proprio NET OS un supporto transazionale per il database. Ultimamente e' quasi scomparso nel nulla, un po' per la presenza di altri sistemi molto piu' efficienti, un po' per il costo della versione Windows delle librerie e molto perche' Novell sostanzialmente non la usa piu' nessuno.

  [annotazioni di Fabio Serra]
  Attualmente è disponibile per Linux e NT. Esistono due versioni: una server ed una workstation. Entrambe supportano Stored Procedure, Trigger, Transazioni e SQL/92. Il costo non mi sembra esagerato: $ 1200 circa per 10 client nella versione server. Ottima interfaccia di amministrazione.

• Raima/Velocis - http://www.birdstep.com/database_technology/rdm.php3
  Viene venduto come il piu' veloce sistema di database file-based, e lo e'. Purtroppo implementa un sistema di "chaining" dei record che finche' funziona e' perfetto, ma quando si sfascia son dolori... Le librerie di accesso ai dati sono distribuite sia come DLL sia come .lib per linkaggio dinamico o statico. Che io sappia, le librerie sono disponibili solo per ambiente Windows.
• Faircom - http://www.faircom.com
  Poco utilizzato ma multipiattaforma, le librerie esistono per Windows e per Unix/Linux.
• Microsoft Access - http://msdn.microsoft.com/office/
  Oltre ad avere una capacita' un po' limitata, ha il problema di gonfiarsi come un pallone per via del modo di gestione interno e richiede pertanto compattazioni periodiche del DB. Supporta un dialetto SQL sufficientemente esteso, ma ha la brutta abitudine di consentire cose piuttosto fuorvianti, come l'accettare nomi di campi che sono parole riservate dell'SQL, con il risultato che poi alcune query non funzionano su altri database e non si capisce perche' (e' successo). Le prestazioni del sistema in condizioni stand-alone e con indici numerici sono eccellenti. Disponibile solo per piattaforma Windows, dovrebbe essere usato solo per applicazioni che gestiscono un piccolo volume di dati o che non fanno troppe modifiche sui dati e con multiutenza medio/piccola (10 utenti sono gia' troppi). Attenzione a non avere problemi di rete se lo si usa in multiutenza.
• FileMaker - http://www.filemaker.com/it/
  [Informazioni di Maury2ma]
  Inizialmente scritto per SO MAC e' divenuto uno dei TOP, da tempo e' disponibile anche per Windows ed e' facilissimo da usare anche per chi non sa assolutamente niente di DB. Viene venduto a prezzi contenuti (rispetto ad altri) e comprende un manuale introduttivo ben fatto. Naturalmente tanta stabilita' e facilita' sono a discapito di potenza e versatilita' (che comunque non e' poca). Permette la pubblicazione su Web, utilizza ODBC e utilizza gli Script. Purtroppo sono ancora in pochi ad usarlo e quindi non si trova molto materiale esplicativo, ma in compenso esistono una marea di Plug-in.
  Esistono due versioni fondamentali (ce ne sono altre secondarie): FileMaker Professional che permette la creazione di DB semplici ed affidabili non permette la creazione di applicazioni eseguibili e FileMaker Developer che e' la versione più completa (e cara) e permette la creazione di DB complessi, affidabli ed applicazioni eseguibili.
• IBM Assistant - link non disponibile, probabilmente non esiste piu'
  [info di Andrea Palazzi]
  Non e' un db, e' un information retrieval system, assolutamente non strutturato, ne' tantomento relazionale o relazionabile. Sono riuscito a farlo andare, cosi' cosi', in w95/98 in nt mica tanto: probabilmente all'avvio va a legggere la parallela e nt non gradisce.

  Dannatamente comodo da impostare: gli archivi possono avere qualunque nome 8+3, on o senza estensione (per cui l'utente tipico non ce la mettte mai). Essendo il formato proprietario il modo piu' comodo di recuperarne i dati, escludendo forse un sw costosuccio di riconversione di cui volendo dovrei ritrovare il link, e' probabilmente di stampare l'archivio su testo, quindi fare un parsing linea per linea sui nomi dei campi. semplice se i campi sono brevi, complicato se il campo slitta su piu' righe. ah si', dbase 3 o 4 aveva un'utilita' (un po' nascosta nei menu) per recuperarne gli archivi, con qualche schifezza nella conversione dei caratteri.

Addendum 8 Aprile 2006
Gestione di archivi ibm assistant sotto windows nt / 2000 / xp.
File/Report Assistant cercano l'accesso diretto alle risorse (stampante ecc). Fatto sta sotto win nt non girano. due opzioni, afaik: 1. non e' piacevole, ma si riesce a far girare assistant su w2k usando vmware con una vm dos. Direi vada obbligatoriamente settato il floppy, che fa/ra cercano. gli archivi sono poi nello zippone vm (mi sembra che vmware abbia aperto il formato in questi giorni), ma con filing assistant li si puo' esportare come file di testo ordinato su cui fare poi parsing. si fatica un po' ma funziona. 2. in w2k si riesce a far girare dbase3+. usando l'assistente di db3 (dopo tanto tempo non ricordo piu' esattamente, ma fra le opzioni si dovrebbe capire, eventualmente dando un'estensione agli archivi assistant) si riuscivano a importare le tabelle fa/ra. in questo caso c'era qualche casino coi caratteri (es. una vocale accentata diventava il chr(133), che in times new roman sono i tre puntini). cmq da dbase poi e' facile recuperare i dati in access.

• SQLite http://www.sqlite.org
  [informazioni di Manlio Perillo] SQLite e' un database SQL file-based pensato per essere incluso in altri programmi e per essere semplice. Supporta quasi pienamente l'SQL-92, inclusi i trigger. Tra le sue caratteristiche principali:
  • la sua tipizzazione e' molto debole. Supporta, in pratica, solo numeri, interi e stringhe (inclusi i BLOB). Tuttavia, ad esempio, in una colonna di tipo intero si puo' inserire del testo.
  • le istruzioni SQL vengono convertite in codice eseguito da una macchina virtuale
  • supporta l'UTF-8 e l'UTF-16
  • e' pienamente transazionale e ACID
  • permette di definire nuove funzioni (inclusi aggregati) e nuovi 'collation'
  • supporta database in modo read-only
  • dato che e' pensato per essere incluso in altre applicazioni, permette la definizioni di diversi hook e fornisce diverse funzioni di supporto.
  IMHO, insieme a PostgreSQL, puo' rispondere ad ogni esigenza.

Database Server, ovvero: basati su una parte "server" che gestisce i dati e comunica con uno o piu' "client" che accedono ai dati comunicando solo ed unicamente con il server. Molto piu' efficienti e flessibili dei file-based sono pero' anche molto piu' costosi e (in generale) richiedono molte piu' risorse di hardware. Sono piu' orientati verso problemi di tipo aziendale (dove i soldi non mancano).

Questo tipo di database sono (in generale) orientati verso un'utilizzo piu' professionale, con volumi di dati dal medio al grosso ed un'impiego in rete locale, dove una macchina (o piu') e' dedicata alla gestione del database.

• MySQL - http://www.mysql.com
  basato su miniSQL, e' un database server OpenSource. Leggero ma efficiente, non supporta Stored Procedure, Triggers et similia ma per molte applicazioni va' piu' che bene. Negli ultimi tempi e' stato (un po' troppo) osannato, forse proprio per via del fatto che sia gratuito. Esiste per Windows e per Unix/Linux.
  MySQL e' piu' orientato a piccole applicazioni e piccoli volumi di dati.
• PostgreSQL - http://www.postgresql.org
  [annotazioni di Fabio Serra]
  E' difficle trovare un database OpenSource che abbia lo stesso numero di caratteristiche. Supporta quasi completamente SQL/92, quindi ha integrita' referenziale, trigger, rule, funzioni e stored procedure. Le funzioni possono essere scritte in vari linguaggi: SQL, PL/PGSQL, PL/TCL, PL/Perl e C. Ha anche una grande quantita' di tipi di dati, alcuni "esoterici" come quelli di tipo geometrico (LINE, CIRCLE, POLYGON etc) o quelli di Rete (CIDR, INET, MACADDR), fino alla possibilita' d'inserire un array all'interno di un campo (CREATE TABLE mioArray int[6]); E' stato scelto dalla Red Hat come database Enterprise e scala molto bene con l'aumentare degli utenti tanto da battere Mysql. E' un po' debole sui tool grafici di amministrazione che comunque sono presenti sia per Linux sia per Win.
  Con la versione 8, PostGre e' anche Win32 nativo, quindi funziona tranquillamente anche su Windows senza dover fare niente di particolare. Manlio Perillo segnala che da una qualche versione non specificata PostGre e' compatibile SQL/99.
• Ocelot - http://www.ocelot.ca/ocelot.htm
  [Informazioni di Lawrence Oluyede] E' un db SQL-99 compliant, non ha un suo dialetto, funziona in modalita' stand-alone o in rete ed e' OpenSource. Abbastanza performante e' distribuito con i driver ODBC. Per chi vuole "farsi le ossa" con l'SQL dovrebbe essere ottimo.
• Informix - http://www-3.ibm.com/software/data/informix/
  Database relazionale tradizionalmente diffuso sui sistemi Unix, ma disponibile anche su Windows e Linux. Il Server e' disponibile in due tipologie: Informix SE (Standard Edition), un motore veloce e semplice da gestire ed IDS (Informix Dynamic Server, prima chiamato "OnLine"), un motore potente e ricco di funzionalita' che per qualche tempo e' stato il principale concorrente di Oracle. Il database e' dotato di numerosi tool di contorno, tra cui un 4GL un tempo molto diffuso. Nel 2001 Informix e' stata acquistata da IBM che sta progettando l'integrazione progressiva dei prodotti Informix e DB2.
• Microsoft SQL Server - http://msdn.microsoft.com/sqlserver/
  pesa come un mattone, costa come una Rolls Royce ed ha lo svantaggio di funzionare solo in ambiente Microsoft. E' disponibile una interfaccia grafica ed una piu' testuale, purtroppo le funzioni piu' avanzate sono disponibili solo attraverso l'interfaccia testuale. Il database supporta parecchie funzionalita' avanzate (Trigger, Stored Procedure, replicazione, schedulazione di operazioni etc. etc). L'interfaccia grafica da' pero' il falso senso di sicurezza che sia molto facile da gestire.
  Il database scala abbastanza bene verso un volume di dati medio, ma io non lo userei su un volume di dati grosso.
  Ne esiste una versione gratuita per scopi di sviluppo (MSDE) che pero' e' priva di molti tools di gestione ed ha delle limitazioni consistenti (5 connessioni contemporanee e 2Gb di spazio di archiviazione). Con i files di progetto .ADP introdotti nella versione 2000, Microsoft Access e' il front-end piu' integrato a SQL Server.
• Oracle - http://www.oracle.com
  pesa come un mattone, costa come una Rolls Royce ma e' solido e stabile come la statua della liberta'. E' il database piu' usato in ambiente aziendale grazie alla sua robustezza ed al fatto che e' disponibile per qualunque piattaforma (Win/Linux/Unix). Supporta Trigger, Stored Procedure, Views e (a seconda della versione) una larga gamma di "features" come tabelle temporanee o partizionate, indici function-based ed altro. Purtroppo tanta flessibilita' si paga: gestirlo non e' uno scherzo.
  Il database scala molto bene verso volumi medio-grandi di dati, e' possibile (per scopi di sviluppo o di istruzione) avere una copia completamente gratuita dell'intero sistema (la documentazione e' in formato elettronico).
• Interbase - http://www.interbase.com/open/downloads/ib_download.html
  di questo ne esistono due "versioni", uno distribuito da Borland ed uno da IBPhoenix (www.boldand.com/interbase e www.ibphoenix.com), multipiattaforma (Windows, Linux e Solaris), supporta Trigger, Stored Procedure ed un tipo particolare di SP dette "Slect Stored Procedure". Richiede meno potenza di Oracle ma e' un po' piu' lento nella connessione, inoltre pare che abbia qualche bug nell'ottimizzazione delle Query.
• Firebird - (Informazioni di Andrea Raimondi) Nato dalle 'ceneri' di Interbase, http://www.firebirdsql.org , tenutaria del sito e' la Firebird Foundation. I due motori stanno piano piano divergendo in modo molto accentuato, specialmente per quanto riguarda le "features": Firebird, infatti, non supporta SMP. Inoltre sono cambiati parecchi aspetti interni anche di base, come per esempio il database principale che - storicamente - in Interbase si e` sempre chiamato ISC4.gdb e che adesso in Firebird si chiama Security.fdb . Sono anche cambiate(e molto) le librerie di accesso, per Interbase e` sempre gds32.dll mentre per Firebird ora si chiama FbClient.dll . Inoltre, Firebird supporta una modalita` "Access like" che consente di scalare facilmente da applicazione desktop a server attraverso una tecnologia, chiamata Firebird Embedded, che consente di aprire un database IN ACCESSO ESCLUSIVO sulla macchina. Questo significa che al massimo UNA istanza di UNA applicazione che usa un determinato DB puo` essere attiva in un certo momento. Riguardo alla connettivita`, esistono driver un po` per tutti i gusti: oltre ai componenti InterBase eXpress disponibili nelle edizioni Pro e successive di Delphi, esistono sempre per Delphi altri componenti come FIBPlus ed IBO, poi esistono i driver per ADO.NET, ADO ed ODBC. Entrambi, inoltre, dispongono di "generators" che sostanzialmente servono, appunto, a generare numeri univoci per un singolo generator. Quindi avendone due puo` capitare che il valore sia uguale, ma comunque globale al generatore usato. Questo meccanismo, inoltre, e` particolarmente utile per creare campi autoincrementanti: tramite essi ed i trigger, infatti, e` possibile generare "al volo" dei valori numerici da utilizzare come chiavi primarie di una tabella. Esistono anche diversi software di amministrazione, al di la` di IBConsole, raggiungibili tramite diversi link sul sito ufficiale. Il piu` conosciuto e famoso, comunque, e` IBExpert, disponibile sia in edizione Personal(gratuita, ma limitata) che a pagamento. Esistono inoltre diverse mailing list su Yahoo per Firebird.

• Sybase - http://www.sybase.com/sdn/
  Originariamente Sybase e Microsoft SQL Server erano la stessa cosa, la versione 6.5 di MS SQL Server era in realta' sviluppata da Sybase, in seguito (per problemi di marketing) le due societa' hanno "divorziato" ed adesso le nuove versioni di Sybase/SQL Server non hanno piu' molti punti di contatto.
• SAP DB - http://www.sap.com/sapdb/
  Database relazionale mantenuto dal gigante SAP. Un'analisi molto superficiale dei sorgenti mi fa prospettare per il casino interno. Assolutamente non di moda, ma non per questo peggio di altri prodotti. Multipiattaforma. Codici sorgenti disponibili.
• Berkeley DB - http://www.sleepycat.com/
  E' piu' un kernel per Server di database che un prodotto a se' stante. Multipiattaforma ed OpenSource.
• DB2 - http://www-4.ibm.com/software/data/db2/library/
  E' il db di IBM, fino a qualche anno fa' era lui il "punto di riferimento", poi e' stato surclassato da Oracle. Multipiattaforma. DB2 e' piu' orientato verso grossi volumi di dati, e su grossi volumi le prestazioni sono ottimali.
• Centura/Gupta-SQL Base - http://www.centurasoft.com/products/sqlbase/sqlbase-prodinfo.asp
  Si tratta di un database piuttosto limitato e poco diffuso, supporta Stored Procedure e trigger, ma il linguaggio di programmazione e' alquanto oscuro e poco propenso alle traduzioni. Dispone pero' di una interfaccia di programmazione che consente la realizzazione di applicazioni che vengono "interpretate" direttamente dal motore di database, consentendo la creazione di una applicazione senza nessun'altro linguaggio di programmazione. Che io sappia esiste solo per Windows.
• Tamino - http://www.softwareag.com/Corporate/products/tamino/default.asp
  E' un database XML-based, cioe' i dati vengono inseriti in documenti XML, il che dovrebbe dire che e' piu' compatibile.

  tratto dalla documentazione di Tamino:
  Tamino XML Server is the first system that can store information in native-XML format. Storing XML data natively has an enormous advantage over relational database management systems (RDBMSs), because no extra data conversion layer is required as, for example, needed for XML-enabled RDBMSs and the document structure is kept intact. Furthermore, RDBMSs are capable of storing XML only when retrofitted with special extensions.

Di questi so' a malapena che esistono (db)...

TODO: TROVARE QUALCUNO CHE NE SAPPIA QUALCHE COSA...

• CA Ingres - http://ca.com/products/ingres/documentation_set.htm
• Mckoi - http://www.mckoi.com/database/docindex.html
• Mimer - http://www.mimer.com/download/default.htm
• CQL++ - http://www.cql.com/
• Gadfly - http://www.chordate.com/gadfly.html voci non confermate dicono sia scritto in Python
• Progress - http://www.progress.com/v9/documentation/
• Yard - http://www.yard.de/
• ThinkSQL - http://www.thinksql.co.uk/

• ERWin - http://www3.ca.com/Solutions/Product.asp?ID=260
  Si tratta di un tool che funziona solamente in ambiente Windows, gestisce piu' o meno tutti i database esistenti (spiccano la mancanza di MySQL e PostgreSQL) e consente il reverse-engineering del database (aka: dal database gia' creato ne estrae la struttura).
  La mia esperienza con tale tool e' stata abbastanza deludente (gli script creati non funzionavano), ma forse sono io che non lo so usare, e a dire la verita' non e' che mi ci sia sprecato troppo sopra.
• ER/Studio - http://www.embarcadero.com/products/erstudio/index.html
  [Informazioni da Marco Quarona]
  Credo esista solo per Windows, gestisce diversi database relazionali (mancano sia mySQL che PostGreSQL), fa il reverse engineering ma solo dai principali dei database fra quelli supportati. Rispetto a ErWin, e' piu' pratico da usare, ma qualche volta (di rado, comunque) si incasina da solo i propri schemi e ha un licensing cervellotico. In grado di generare anche stored procedures, triggers e oggetti specifici ad un database. Dalle ultime versioni (7.6) lavora anche in XML. Non e' rapidissimo se deve gestire schemi molto grandi.
• Case Studio - www.casestudio.com/enu/
  
• Data Architect - www.thekompany.com/products/dataarchitect/
  Specifico per MySQL e PostgreSQL, e' disponibile sia in ambiente Windows che in ambiente Linux. Non e' free ma costa meno di 50$ (credo).
• Dezign for database - http://www.datanamic.com/products.html
  
• DIA - http://www.lysator.liu.se/~alla/dia/
  [informazioni fornite da Francesco Lamonica]
  Dia e' un programma che permette di creare diagrammi e schemi di vario genere, usa un'interfaccia piuttosto semplice ed intuitiva e permette di creare i diagrammi scegliendo gli oggetti da una serie di librerie (fornite col programma) che spaziano dai circuiti integrati ai diagrammi UML. Non e' pertanto specificamente pensato per i database. La versione corrente e' la 0.9, basata sulle librerie Gnome 1.x e' presente una versione Windows. Dalla prossima release passera' alle Gtk-2.x.
• DB Designer - http://dbdesigner.sourceforge.net/
  Informazioni di Carlo Vaccari
  Il progetto e' fermo dal 2001, esiste pero' un progetto equivalente di FabForce: http://www.fabforce.net/dbdesigner4/ E' un tool visuale per la progettazione, creazione e manutenzione di database. E' rilasciato con licenza GPL ed e' pensato essenzialmente per MySQL, anche se si puo' interfacciare con Oracle e SQL Server via ODBC (ed anche con qualunque altra cosa che abbia un'interfaccia ODBC ovviamente). E' disponibile sia per Linux che per Windows. Io l'ho provato e non e' affatto male.
• Visual DBM - http://www.yrsoft.com/vdbm/vdbm.html
  

Portare i dati da un db ad un'altro e' gia' di per se' una cosa poco bella da fare, soprattutto se si passa da un database file-based ad un relazionale o client/server. In ogni caso bisognerebbe prendersi un po' di tempo e vedere bene cosa conviene fare, se e' sensato e possibile fare un trasferimento 1-1 dei dati e della struttura verso il nuovo database, o se ha piu' senso rivedere in toto la struttura del database per adattarla al nuovo DBMS e sfruttarne a fondo le caratteristiche. Molte applicazioni che funzionavano benissimo con un database, mostrano prestazioni deludenti (o in casi estremi, assolutamente inaccettabili) una volta portate su un'altro DBMS.

Per il trasferimento dei dati da un DBMS ad un'altro io consiglio sempre di costruire per prima cosa la struttura dati nuova sul DBMS di destinazione, quindi importare i dati da un DBMS all'altro, eventualmente scrivendo delle apposite procedure di conversione, e di non fidarsi dei vari "wizard" che sono messi a disposizione dai produttori. Tali wizard possono funzionare benissimo in alcuni casi, ma malissimo in altri casi, ed in ogni caso e' necessario controllare attentamente i dati finali (non volete terminare tutto e poi scoprire che la vostra anagrafica da 45.000 records e' andata a ramengo vero?).

Attenzione: con o senza "wizard" molto spesso le operazioni di conversione sono one-way-only. Cioe' e' possibile portare i dati da A a B, ma non viceversa. Quindi pensate bene a quello che fate e pianificate accuratamente le operazioni.

Su http://www.rot13.org/~dpavlin/sql.html sono riportati vari script, programmi ed altre cose per fare il porting da un database ad un altro (per lo piu' MySQL e PostGre). Magari c'e' qualche cosa che fa per voi.

PRIMA di mandare il messaggio fatti un giretto su Google e dai un'occhiata ai messaggi vecchi, magari la risposta e' li' e risparmi un messaggio, se proprio non trovi nulla, manda, pero' assicurati

• di avere specificato che database/versione stai usando o ti proponi di usare
• di avere descritto COSA vuoi ottenere e non il COME
• se ottieni un errore, riporta l'errore e tutti i dettagli corrispondenti, dire "non funziona" non aiuta a capire quale puo' essere il problema
• di avere fornito abbastanza informazioni da capire quale sia il problema ed eventualmente riprodurlo, senza pero' scrivere la Divina Commedia
• di avere usato un linguaggio umano, possibilmente senza troppi errori di grammatica, senza strane sostituzioni di caratteri (cose' st'idea di sostituire "ch" con "k" ???) e con un linguaggio abbastanza "garbato": ricordati che sei tu che chiedi aiuto

Il problema in questo caso e' reperire il minor numero possibile di record dal database e/o visualizzare il "blocco" giusto.

Puo' essere affrontato in vari modi, piu' o meno efficienti.

nota di Davide Bianchi: tutto il problema e' insignificante a mio parere, una query che ritorna piu' di 100 record e' sicuramente sbagliata, nessuno si mettera' mai a guardarsi piu' di 100 risultati, se nel vostro sistema/applicazione/sito web piu' del 10% di query ritornano piu' di 100 record e' ora di rivedere la struttura del database o i criteri di ricerca.

Il primo modo di affrontare il problema e' quello di usare un cursore scrollabile, reperire tutti i record, quindi spostarsi di un certo numero di 'pagine' mediante le funzionalita' del cursore e visualizzare la 'pagina' giusta.

Problemi: non sempre il cursore scrollabile e' disponibile, dipende dal database e dal driver, reperire *tutti* i record puo' richiedere molto tempo e questi record vengono tenuti in memoria (elevato consumo di risorse quindi), l'utente puo' scocciarsi etc. etc.

Il secondo metodo e' quello di reperire solo il numero di record "utili", per fare cio' e' necessario avere un qualche tipo di "identificatore" che "marchi" l'inizio e la fine della "pagina", quindi reperire solamente da ID_inizio_pagina + (numero righe) + 1 fino a ID_inizio_pagina + (numero_righe * 2). In modo da avere esattamente le righe da visualizzare. Ovviamente dobbiamo tenerci ID_inizio_pagina in memoria da qualche parte.

Problemi: se il resultset non e' ordinato in modo acconcio, per reperire il gruppo di record il database dovra' estrarsi comunque tutti i dati e quindi ordinarli, quindi ci mettera' il doppio del tempo, l'ID lo dobbiamo memorizzare da qualche parte, quindi o lo scriviamo nella pagina e lo reperiamo dopo o e' in sessione, tutti sistemi che si prestano a problemi ed errori (la sessione puo' scadere, l'ID puo' essere alterato etc.).

Risultato finale: non esiste un sistema ottimale, il "miglior" sistema dipende da cosa state facendo, quale linguaggio utilizzate, il tipo di database/driver e la possibilita' che una query ritorno o meno una caterva di risultati.

Informazione di Paolo Fiore (22/5/2003): Mondadori sta stampando nella collana "Miti Infomatici" (brossura, tascabile) dei "signori" manuali altrimenti costosi. In particolare ho appena acquistato: "SQL Query for Mere Mortals" titotlo italiano "SQL Query" a 10 euri invece di piu' di 40! Il testo a parte gli errori di stampa e qualche traduzione discutibile (quanto tempo ci vuole a ritradurre "valori sconosciuti"?) mi sembra una cosina veramnete interessante (il capitolo sulle join e' un must). Qui trovate la lista dei libri disponibili.

--TODO: AGGIUNGERNE QUALCUNO---

Generici/Progettazione dei database

Data Analysis for Database Design
Davide Howe - BH - ISBN 0-7506-5086-9
Questo invece non mi e' piaciuto neanche un po'. Non per i contenuti che sono tutti giusti, ma per l'esposizione troppo pedante e scolastica.

Fundamentals of database systems (http://www.aw.com/cssupport/ElmasriNavathe.html), segnalato da Antonio Limone che dice:E' il libro che ho usato all'universita', non ho letto la terza edizione, ma la seconda non era male.

PostGreSQL

Oracle

Oracle 8i DBA Handbook
Loney/Theriault - Osborne - ISBN 0-07-212188-2
E' un compendio di cose utili per il DBA, dai problemi piu' comuni a come operare un 'tuning' di un database.

Database
Letteralmente: "base di dati", originariamente indicava l'insieme di informazioni utilizzate da un programma per fare il suo lavoro, poi e' passato ad identificare l'insieme di librerire/programmi per la gestione dei suddetti dati o l'insieme di librerie/programmi e dati (vedi anche dbms e rdbms).

Structured Query Language - SQL
Il linguaggio SQL e' stato inventato agli inizi degli anni 90 come sistema "standard" per interrogare un DBMS ed ottenere informazioni. Si proponeva di diventare la lingua franca dei database. Purtroppo, un po' per via di rivalita' tra i vari produttori, un po' per via delle "features" speciali introdotte nei vari prodotti, l'SQL e' ben lungi dall'essere "standard". In particolare, ogni database ha un suo "dialetto" con keyword e costrutti specifici.
A questo va' aggiunto che l'SQL e' indicato solo per interrogazioni dei dati di tipo semplice, con l'accrescere della potenza dei DBMS si e' sentito il bisogno di fornire un qualche cosa di piu' efficiente per incorporare "programmi" nel database stesso, questo ha visto la nascita delle Stored Procedures, Triggers ed altre cose, ma ha anche portato alla creazione di diversi SQL "accresciuti" dei costrutti necessari a supportare cicli, controllo errori etc. etc.

Stored Procedure
Una S.P. e' un blocco di codice SQL (che puo' contenere istruzioni di interrogazione al database, cicli, operazioni matematiche e quant'altro il DBMS consente) "chiuso" dentro al database stesso. La S.P. viene "compilata" una volta quando viene creata, dopodiche' puo' essere richiamata ogni volta che e' necessario. Questo e' in un certo senso positivo, perche' consente di "chiudere" nel database tutta una serie di operazioni ripetitive che altrimenti sarebbe necessario attuare a mano (es. aggiornare il campo "totale fattura" ogni volta che si modifica una riga della stessa), ma in altro senso richiede un altro pezzo di codice, scritto in un differente linguaggio, da mantenere.

Trigger
Un Trigger e' sostanzialmente una Stored Procedure (vedi sopra), che pero' viene attivata automaticamente dal DBMS stesso in risposta ad una operazione di modifica dei dati. I Trigger sono solitamente "applicati" ad una specifica tabella e possono essere attivati da operazioni quali l'aggiunta di uno o piu' record, la modifica di uno o piu' record o la cancellazione di uno o piu' record. I Trigger si dividono in "pre" e "post". Un trigger "pre" viene richiamato PRIMA che il DBMS proceda all'operazione, quindi il record su cui agisce contiene i dati prima che questi vengano inseriti/modificati/cancellati, un trigger "post" viene chiamato DOPO l'operazione. I Trigger in genere hanno delle limitazioni in cio' che possono fare, per esempio, operazioni di creazione/distruzione di tabelle non sono solitamente ammesse, alcuni DBMS non consentono al trigger di modificare i dati della stessa tabella su cui il trigger e' applicato (chiamata ricorsiva).

DBMS
DataBase Management System. Con questo termine ci si riferisce esplicitamente al sistema usato per gestire i dati (e non ai dati in se'). Esistono vari tipi di DBMS, con diverse caratteristiche e diverse applicazioni. Tipicamente dividiamo in Relazionali (RDBMS) e ad Oggetti (OODBMS). Un'altra suddivisione puo' essere tra DBMS file-based e client/server.

Relational DBMS (RDBMS)
Un DBMS si dice Relazionale (RDBMS) se implementa le 12 "regolette" della semantica relazionale. Che significa tutto questo ? Sostanzialmente che il database utilizza certi meccanismi per ricercare, memorizzare ed organizzare i dati al suo interno e che questo implica un certo modo di gestione/organizzazione dei dati prima ancora che questi possano essere dati in pasto al DBMS. In particolare, ogni tabella in un RDBMS deve avere una chiave univoca (vedi primary key), le singole tabelle in un RDBMS possono essere messe in "relazione" tra di loro usando il valore di alcuni campi come "collante" tra le tabelle.

Object-Oriented DBMS (OODBMS)
Si tratta di una evoluzione dei DBMS avvenuta negli ultimi anni, mentre un normale DBMS memorizza "record" di dati, un OODBMS memorizza "oggetti", e questi oggetti possono essere in relazione uno con l'altro in base a determinate caratteristiche.
Vedere Objectivity
TODO: aggiungere qualche altro link esplicativo...

Client/Server
Un DBMS si definisce client/server (o semplicemente server), se e' composto da due parti, una delle quali e' una applicazione (server) a se' stante che accede ai dati veri e propri, mentre la seconda parte (il client) puo' essere una applicazione o un set di librerie e non accede ai dati direttamente ma mediante "comunicazione" con il server, la comunicazione avviene solitamente mediante meccanismi di rete locale, quindi le due parti possono anche essere su due computer differenti posti in luoghi diversi, finche' vi e' una connessione di rete (internet o quant'altro) che li possa connettere.
Un Server di database e' in genere molto piu' costoso di un file-based e richiede molta piu' potenza (hardware), solitamente sono relazionali o object-oriented, supportano l'SQL, scalano piu' o meno bene (dipende dal database) e supportano l'utilizzo multiutente.

File-Based
Un DBMS si definisce file-based quando tutti i dati sono memorizzati in uno o piu' file, e il DBMS stesso altro non e' che una applicazione o un set di librerie che accede direttamente ai dati. Questo tipo di database in genere non sono relazionali, sono relativamente poco costosi, molto rapidi per operazioni su singole tabelle e su basi di dati poco estese (<=100.000 record per tabella), scalano poco bene e sono indicati solo per un'utilizzo mono-utente.

Backup - Hot/Cold Backup
Viene detto "backup" la copia di sicurezza dei dati gestiti da un DBMS (ed e' sempre meglio averne/farne una). I backup si dividono in "caldi" (hot) o "freddi" (cold), a seconda che siano effettuati mentre il database sta' funzionando o e' fermo. Nel primo caso, il backup deve essere effettuato usando un qualche tool o sistema fornito dal database stesso, altrimenti si rischia di avere una copia non funzionale (i dati sono in quel momento aggiornati, quindi i dati che finiscono nel backup possono essere incompleti o corrotti), nel secondo caso si possono usare i normali comandi di copia del sistema operativo su cui si lavora per copiare tutti i file in cui il DBMS memorizza le informazioni. Chiaramente, nel secondo caso il database deve essere fermo, quindi nessuno ci puo' lavorare sopra.
Un'altra suddivisione di backup e' tra backup "logici" o "fisici", il primo tipo e' in generale ottenuto con un qualche tool specifico del database e consente di ottenere la copia delle strutture interne del DBMS (da un singolo record/tabella fino al piu' grosso elemento in cui il DBMS memorizza i dati), mentre un backup "fisico" si effettua copiando tutti i files di cui il DBMS e' composto. Di solito un "hot" backup e' anche un backup "logico", mentre un "cold" backup e' un backup fisico. Alcuni DBMS consentono di prendere hot-fisical-backup utilizzando particolari accorgimenti.

Primary Key - PK - Chiave Primaria
Si definisce "Primary Key" (PK) di una tabella, il singolo campo o insieme di campi il cui valore identifica UNIVOCAMENTE il record all'interno della tabella.
In un database relazionale ogni tabella deve avere una (ed una sola) PK.
In alcuni casi e' possibile "creare" la PK usando un'insieme di informazioni gia' presenti nel record stesso (es. la targa di un'auto e' univoca, quindi e' un'ottima PK), in altri casi non si riesce a trovare nessun insieme di campi che componga un valore sufficientemente "univoco" (es. nome+cognome in un'anagrafica non e' una PK "credibile"), quindi e' necessario aggiungere un campo costruito e valorizzato appositamente. Molti database hanno dei sistemi che consentono la generazione di una PK indipendentemente dai valori del record (di solito sono dei meccanismi di contatori incrementali), il grosso problema in questo caso e' come recuperare il valore generato dal database subito dopo l'inserimento o se tale valore e' disponibile prima dell'inserimento.

Foreign Key - FK - Chiave Riferita
Si definisce "Foreign Key" (FK) uno o piu' campi di una tabella il cui valore deve essere presente come PK in un'altra tabella.
Tipico esempio di FK e' in una coppia di tabelle "Fatture" - "Righe di Fattura", il campo che unisce la singola riga alla fattura.
Le FK sono solitamente usate per assicurare la coerenza delle informazioni inserite nel database (integrita' relazionale). Una tabella puo' avere qualunque numero di FK.