Scelta del RDBMS

Tenendo conto delle considerazioni sinora effettuate riguardo la scelta di soluzioni Open Source, molti tra i prodotti più diffusi e maturi sono stati considerati.

Tabella 4.2: Limiti di alcuni noti RDBMS Open Source

MySQL 5 PostgreSQL SQLite

Max DB size Unlimited Unlimited 32 TB (230 pages * 32 KB max page size)

Max table size 2 GB (W in32 FAT32) to _{16 TB (Solaris)} 32 TB ?

Max row size 64 KB 1.6 TB ?

Max columns per row 3398 250-1600 depending on

type 2000

Max Blob/Clob size 4 GB (longtext, longblob) 1 GB (text, bytea) - _{stored inline} 1 GB

Max CHAR size 64 KB (text) 1 GB 1 GB

Max NUMBER size 64 bits Unlimited 64 bits

Min DATE v alue 1000 -4713 No DATE type

Di seguito sono discussi a titolo di esempio i termini che hanno portato alla scelta finale, tra tre dei concorrenti ritenuti più interessanti, ovvero MySQL, PostgreSQL e SQLite. Osserviamo in primo luogo i limiti tecnici (relativi al momento in cui si è operato il confronto) dei tre database per compararli in Tabella 4.2. Da tale tabella si può notare che MySQL e PostgreSQL non hanno limiti alla dimensione massima del database mentre SQLite ha un limite.

Tale limite, anche se può sembrare particolarmente elevato, rappresenta per il progetto una rilevante limitazione, poiché il database sarà continuamente alimentato dai dati inviati da un numero arbitrario di terminali remoti e dispositivi di vario genere: per questo una limitazione alla dimensione del database potrebbe costringere all'impiego di più di un database e alla conseguente revisione ed adeguamento di tutte le strutture di controllo, ricerca e inserimento dei dati. Tale situazione non è ovviamente desiderabile nel caso si voglia realizzare uno Standard Internazionale e quindi si pensi a sistemi con meno vincoli possibili. E’ anche vero che in astratto è possibile immaginare una architettura indipendente dai dettagli implementativi del singolo RDBMS, ma tale situazione è ideale, nella realtà conviene tener conto in fase di progetto di eventuali limitazioni imposte. Tale limitazione della quota del database in SQLite è dunque un elemento la cui rilevanza ai fini progettuali non è da non sottovalutarsi. Per quanto riguarda le altre tipologie di limitazioni dei database possono considerarsi meno vincolanti per la scelta dell'uno o dell'altro prodotto, ma in ogni caso è da considerare la generale migliore performance di PostgreSQL.

Vediamo ora in Tabella 4.3 i principali elementi che caratterizzano un RDBMS:

Tabella 4.3: Caratteristiche degli RDBMS

MySQL PostgreSQL SQLite

ACID Yes Yes Yes

Referential integrity Yes Yes No

Transactions Yes Yes Basic

Unicode Partial Yes Yes

Come si può notare tutti e 3 i RDBMS hanno le proprietà ACID (Atomicità, Coerenza, Isolamento, Durabilità), essenziali per un sistema qualitativamente performante.

SQLite però non ha pieno supporto all'integrità referenziale, e questo rappresenta un elemento negativo. Dato che, in fase operativa, saranno diversi i terminali e gli utenti che accederanno contemporaneamente al database, l'integrità referenziale diventa una caratteristica assai determinante, in quanto garantisce che, nel caso di numerosi accessi contemporanei alla stessa tabella, non si verifichino conflitti (ad esempio impedisce la generazione di record duplicati in un campo chiave).

Nella fattispecie, una sorta di integrità referenziale può essere assicurata anche grazie all'impiego dei triggers, ma si tratta comunque di una modalità di gestione più macchinosa, e che richiede comunque un costante monitoraggio.

In relazione alle altre caratteristiche, non sono osservabili differenze di entità tale da poter incidere in maniera determinante sulla scelta del prodotto, anche se permane in generale una performance migliore di PostgreSQL.

Osserviamo ora le principali funzionalità aggiuntive che possono essere previste in un RDBMS in Tabella 4.4:

Tabella 4.4: Principali funzionalità aggiuntive degli RDBMS

Da questa tabella possiamo notare che MySQL non gestisce l' "Intersect" e l' "Except".

MySQL PostgreSQL SQLite

Union Yes Yes Yes

Intersect No Yes Yes

Except No Yes Yes

Inner joins Yes Yes Yes

Outer joins Yes Yes Yes

Inner selects Yes Yes Yes

Merge joins Yes Yes ?

Except è un operando che è possibile inserire tra query in una riga di comando. Come risultato si ottengono tutti i valori distinti della query a sinistra dell'operando non presenti nella query a destra.

Intersect è anch'esso un operando che è possibile inserire tra query in una riga di comando. Il risultato è però formato da tutti i valori distinti restituiti da entrambe le query a sinistra e a destra dell'operando.

Poiché non è ai fini progettuali sostanzialmente rilevante stabilire come i dati immagazzinati nel sistema saranno successivamente fruiti, non è possibile valutare a priori se tale elemento potrà costituire una effettiva limitazione all'ambiente.

È doveroso osservare che i risultati ottenibili da questi due operandi possano altresì essere ottenuti in altro modo, tramite cioè i comandi disponibili su MySQL, ma tale procedimento appare più macchinoso e complesso: possiamo perciò considerarlo un elemento a sfavore di MySQL.

Si può dunque rilevare che, in relazione alle funzionalità aggiuntive, non si apprezzano sostanziali differenze in riferimento al progetto, se non una lieve scomodità nell'applicazione pratica di MySQL.

Dalla precedente analisi possiamo soltanto dedurre che l'RDBMS SQLite pare non essere il prodotto più adatto al nostro tipo di progetto.

Ma per operare una scelta tra MySQL e PostgreSQL occorre ottenere un altro parametro: la velocità del sistema. Vi è una particolarità che differenzia in maniera sostanziale MySQL da PostgreSQL: l'uso del "lock".

Quando un utente interagisce con i dati, il sistema li blocca eseguendo un lock, in modo che questi non siano accessibili da altri utenti. Tale protezione è indispensabile per evitare il verificarsi di accessi contemporanei che modifichino lo stesso dato, e venga così minata la coerenza del database.

La principale differenza sta nel fatto che MySQL esegue il lock a livello di tabella (mentre un utente sta interagendo con una tabella, questa viene interamente inibita all'utilizzo da parte di altri utenti), PostgreSQL invece lo esegue a livello di record (mentre un utente interagisce con una riga di una tabella, gli altri utenti non possono contemporaneamente interagire con la medesima riga).

Il lock a livello di record è assai più lento rispetto quello a livello di tabella, poiché è necessario prima scegliere il record da bloccare (utilizzando il comando select) e poi

bloccarlo. Tale operazione avviene in maniera completamente trasparente per l'utente ma causa altresì un rallentamento del sistema.

Di contro, con il lock a livello di record, se due utenti cercano di modificare dati nella stessa tabella ma in record differenti non è necessario che attendano che la tabella venga rilasciata dal lock.

Tale meccanismo crea una differenza importante: MySQL è più veloce se le dimensioni sono piccole e vi è un singolo utente, man mano però che le dimensioni e gli utenti aumentano, PostgreSQL diventa sempre più performante mentre MySQL risente sempre dei medesimi tempi di attesa.

Poiché nel progetto è prevista la presenza di molti terminali all'interno di una flotta e un numero di utenti potenzialmente altrettanto elevato, il fatto che un sistema scali bene verso l'alto, sia cioè sempre più performante con l'aumentare degli utenti, è un parametro di profonda rilevanza, che ha dunque fatto pendere pesantemente l’ago della bilancia nella scelta di PostgreSQL.

I ragionamenti sin qui esposti sono esemplificativi del complesso processo necessario nella valutazione di ogni singolo componente quando si intenda progettare uno standard. Alcuni dettagli implementativi per quanto possano sembrare poco inerenti il discorso generale della standardizzazione ne possono minare la effettiva applicabilità rendendo vano il lavoro di standardizzazione. Per questo motivo è necessario procedere con la massima attenzione considerando il maggior numero possibile di dettagli teorici e di implementazione, al fine di produrre uno Standard realmente applicabile.