MyErp Sistema MyErp Sistema - L'innovazione al servizio del Cliente!

MyErp Area Software - Tipi di database

Dettagli

Visite: 32264

Approfondimento tecnico: tipi di database, caratteristiche e differenze

In primo luogo ci sono due tipi di database: i database file-server e quelli client-server. Sono due mondi completamente diversi. Esempi di database file-server sono p.es. SQLite, MS Access, Filemaker, il database di LibreOffice/OpenOffice; Esempi di database client-server sono ad esempio Firebird, PostgreSql, Oracle, MySQL (in particolare con le tabelle InnoDb), Interbase, MS Sql Server.

I database file-server sono semplici files, a cui i programmi che li usano possono facilmente accedere per inserire, visualizzare, modificare o cancellare i dati in essi contenuti. Questo semplifica al massimo l'installazione, è possibile realizzare programmi che sono autoinstallanti, spesso non c'è da configurare assolutamente nulla. Quando occorre accedere al database il sistema accede fisicamente al file, questo significa che se il file è di ridotte dimensioni l'accesso rimane piuttosto veloce, mentre se il file comincia a diventare di dimensioni più rilevanti, e magari si trova sul server e non in locale, i limiti cominciano a diventare più evidenti, se a questo poi aggiungiamo l'accesso contestuale al database da parte di più utenti (situazione tipica di una rete aziendale) cominciamo a capire come un database di tipo file-server non sia proprio il massimo per sistemi gestionali aziendali.

I sistemi file-server sono stati pensati per usi limitati, database con relativamente pochi dati, da usarsi preferibilmente in locale o, in caso di rete, in piccole LAN di pochi utenti. Sono i sistemi ideali dove i dati sono tendenzialmente pochi e dove non vengano richieste particolari prestazioni di velocità o di sicurezza.

Può essere ad esempio il caso di piccoli database per uso personale (archiviazione dei CD di casa, gestione delle spese domestiche, ecc.), o di piccoli files aziendali per elaborazioni magari tendenzialmente in locale (l'elenco dei comuni italiani che utilizza un software di compilazione moduli, un'elaborazione di un file presenze in locale, un piccolo modulo per l'effettuazione di preventivi, e così via).

Questi sistemi permettono di avere un sistema di accesso ai dati senza doversi preoccupare di nessun tipo di installazione, né di configurazione. Semplicità e immediatezza sono le parole chiave. Occorre che però sia chiaro che non sono sistemi pensati per gestire grosse moli di dati, o per offrire un puntuale controllo di sicurezza e dei permessi degli utenti. Ma è soprattutto quando questi sistemi cominciano ad essere utilizzati in rete (anche una semplicissima LAN aziendale) che iniziano ad vedersi i loro limiti.

I database client-server sono completamente diversi. Prima di tutto occorre installare il database sul server, configurarlo, quindi installare una libreria sui vari clients che permetta di "colloquiare" con il motore del database sul server attraverso la LAN aziendale. Quindi scordiamoci subito l'installazione automatica con doppio click e via. Anche perché occorre comunque configurare la rete con i permessi dei vari utenti. Insomma, qui si parla di sicurezza. Questa operazione si può fare in pochi minuti come in ore di lavoro, dipende da quale database andiamo ad installare, dalla complessità della rete, e così via.

Ma qual'è il vantaggio di un sistema RDBMS, sigla utilizzata per distinguere appunto un database Client/Server? Un RDBMS lavora in maniera completamente diversa rispetto ad un sistema file-server. I clients (pc locali) non accedono fisicamente al file sul database, inviano solamente al motore del database la loro query (letteralmente interrogazione, ossia la richiesta dei dati che occorrono, p.es. mi serve la partita IVA della ditta Rossi) ed il server restituisce solamente i dati richiesti (nell'esempio la partita IVA della ditta Rossi). Quindi il client non deve né accedere né tanto meno elaborare tutto il file fisico del database per ottenere i (pochi) dati che servono, invia una richiesta di quei dati al motore di gestione del database sul server e, da questo, riceve solo e soltanto i dati richiesti.

Questo va a tutto vantaggio della velocità, del bassissimo impegno della LAN (rete aziendale), della sicurezza (i clients non accedono direttamente al db, ma dialogano con il server), al crescere delle dimensioni del database il tempo di una query rimane identico, perché attraverso  la LAN viaggiano e continueranno a viaggiare solamente la richiesta (query) ed i dati restituiti, la dimensione del database diventa alla fine irrilevante.

Analogamente, il motore del database è in grado di gestire tutte le connessioni simultanee da parte degli utenti, ed utilizzare al meglio le prestazioni dell'hardware che, normalmente, su di un server sono assai elevate (multiprocessore, RAM adeguata, ecc.).

Ma a parte la questione prestazionale, sulla quale si potrebbe dire "la mia azienda è piccola, i dati sono pochi", e così via, c'è una differenza abissale per quanto concerne la sicurezza. I sistemi RDBMS sono studiati e lungamente testati per offrire la massima sicurezza dei dati in tutte le condizioni possibili. Se su un sistema file-server potrebbe succedere che in determinate situazioni il file arrivi ad essere corrotto (termine tecnico), questo non deve potere succedere, mai e per nessuna ragione, su un sistema RDBMS.

La sicurezza non viene garantita solo a livello di gestione del motore del database, ma anche grazie alle funzioni che i RDBMS normalmente offrono, affinché gli sviluppatori dei software gestionali (o di altri software che utilizzino comunque il database) possono utilizzarle per offrire la migliore sicurezza dei dati.

Quali sono queste caratteristiche? Il supporto delle relazioni, delle transazioni , dei triggers, di viste, generatori e Stored Procedures. In particolare le relazioni e le transazioni sono caratteristiche talmente importanti da essere irrinunciabili se vogliamo avere la massima sicurezza dei dati.

Le relazioni permettono di impostare a livello di server i necessari collegamenti tra le tabelle. Ad esempio la correlazione tra i clienti e la gestione dei documenti. Se si emette un documento ad un cliente e poi si tenta di cancellare l'anagrafica di quel cliente, il motore del database interviene ed impedisce l'operazione, per evitare che il documento faccia riferimento ad un codice non più esistente. Oppure se si elimina un record di testata di una registrazione contabile, occorre di conseguenza eliminare anche i records di dettaglio della stessa registrazione, ad esempio quelli contabili ed IVA.

Tutte le tabelle di un sistema gestionale aziendale sono tra loro collegate, la mancaza della gestione delle relazioni può portare a grossi problemi circa l'integrità dei dati. Molti possono rispondere dicendo che è il software applicativo (p.es. il gestionale che accede al database) a farsi carico di questi controlli, ma se il controllo non viene fatto a livello di server (e quindi in maniera indipendente dall'applicativo) cosa succede se in un determinato caso, magari a causa di una situazione non prevista, il controllo non viene fatto?  Eppure potrebbe succedere, magari anche a causa del continuo lavoro di implementazione del software che il continuo evolversi della normativa a livello contabile e fiscale richiede. Possiamo permetterci il rischio di avere problemi sui dati aziendali? E cosa succederà mai se un record correlato ad una registrazione viene cancellato da un utente nella frazione di secondo immediatamente successiva al controllo fatto dall'applicativo, a causa della contestualità degli accessi degli utenti della LAN (rete aziendale)?

Le transazioni sono un'altra caratteristica irrinunciabile. Molte operazioni, ad esempio l'emissione di documenti, le registrazioni contabili, ecc., si compongono di una testata e di un dettaglio. Ad esempio i dati generali di una fattura (cliente, numero documento, pagamento, ecc.) ed il dettaglio articoli (righe) della stessa fattura. La transazione consente di considerare unitariamente l'inserimento di tutti i records collegati, testata e dettaglio. Quindi se si verifica un problema dopo avere inserito sul server la testata e non tutte le righe di dettaglio, l'operazione viene annullata e non ci troviamo una registrazione inserita solo in parte, nell'esempio testata con solo alcune righe di dettaglio, quando invece le righe di dettaglio erano di più.

Queste funzionalità sono talmente importanti che alcuni database file-server hanno cercato con il tempo di introdurle anche loro, anche se spesso con risultati tutto sommato non entusiasmanti, nel senso che comunque un database file-server non raggiunge e non raggiungerà mai una sicurezza ed una performance tali da potere essere anche minimamente comparato ad un RDBMS.

Infatti, mentre un RDBMS supporta in maniera eccellente tutte queste funzioni in ragione della sua robustezza, il database file-server può presentare talvolta rischi di corruzione della base dati, soprattutto se utilizzato al di fuori dell'ambito per cui è pensato, ossia per piccoli database in monoutenza o al massimo condivisi tra pochi utenti.

Ritornando all'esempio di tipo automobilistico fatto prima, sarebbe come utilizzare un furgoncino per trasportare dieci bancali di mattoni, oppure un'utilitaria per fare un viaggio di migliaia di chilometri. E questo vale anche al contrario, in città è più agevole un'utilitaria, e per consegnare nei centri storici è sicuramente meglio un piccolo furgoncino di un camion.

Si tratta ancora una volta di capire l'uso per cui un determinato database è stato pensato. Nessuno si sognerebbe mai di utilizzare un RDBMS per un programma di gestione delle entrate e delle uscite del bilancio familiare, ma nessuno dovrebbe neppure sognarsi di usare un database file-server per un sistema di gestione aziendale, magari solamente per semplificarsi la vita e potere fornire così pacchetti autoinstallanti.

Nella speranza che queste poche ma importanti informazioni di tipo tecnico possano comunque essere d'aiuto, anche al di fuori MyErp Software Gestionale, alle aziende che si accingono a valutare un software di tipo gestionale, si ricorda che lo staff di MyErp Sistema è sempre a disposizione per qualsiasi chiarimento o approfondimento.