Eccomi qui, a scrivere di uno dei miei programmi (o librerie, ancora non so come strutturare la cosa) che è tanto in voga in questo periodo della mia vita (leggasi: quello che voglio fare nelle vacanze). Tanto per farla corta, si tratta di un server che accetta connessioni da client che si autenticano, e mantiene certe informazioni su di essi. Trattasi di server che, molto probabilmente, non gireranno sotto "cluster" o diavolerie del genere, ma in vecchi rottami casalinghi od ospitati su macchine virtuali, e quindi molto probabilmente non avranno la fortuna di avere un server database in una macchina "dedicata".
Tralasciando gli accrocchi strutturali dei vari protocolli, ecc., mi son trovato di fronte al problema di creare un sistema in grado di memorizzare questi dati, possibilmente anche molto "complicati", e di accederci in modo veloce. Questo mi lascia sostanzialmente di fronte a due "grandi" possibilità: database e "non database".
I vantaggi di una soluzione con database sono subito chiari: tali software sono scritti per compiere quel tipo di lavoro, quindi la possibilità che il codice sia ottimizzato è superiore. Inoltre, la ricerca è semplice, e soprattutto si demanda questa (come anche altre operazioni "semplici") ad un motore esterno (aka: ce ne freghiamo e ci concentriamo sul resto). Il che sostanzialmente è buona cosa, ma alcune volte non basta.
Immaginiamo di dover memorizzare una lista di utenti, e che tale lista contenga diversi campi, tra cui "nomeutente" (che guarda caso ci servirà per pescare la riga dell'utente all'autenticazione) e "prodottipreferiti" (una lista di prodotti diversa per ogni utente). Ora, un database sarà un po' più complicato da gestire con questo ultimo campo, visto che si tratta di una lista e non di un "normale dato". Questo infatti ci porta a creare una seconda tabella con i dati delle liste, e mediante dei campi "utente", collegarli all'utente (in uno dei tanti casi, alla fine comunque tutti rispecchiano questo concetto). Inoltre, in ambito di diffusione del prodotto, porta un grave problema: il motore del database, eccezion fatta per SQLite e soluzioni simili, va portato dietro, oppure va messo tra i prerequisiti, che non tutti potrebbero avere (e questo quindi complica la vita a chi deve utilizzare il programma).
Potremmo quindi creare una classe con i campi qui di sopra, e creare un vettore di oggetti di questa classe. Questo sarebbe un sistema molto più vicino al nostro utilizzo dei dati, ma deve essere implementato "in toto", e la possibilità di ottimizzazione è bassa. Inoltre, va previsto un modo per salvare gli oggetti in file, e qui per fortuna Java ci da una mano, grazie alla possibilità di serializzare gli oggetti.
Tirando le conclusioni, possiamo dire che, se da un punto di vista architetturale e algoritmico utilizzare un motore di database esterno porta vantaggi notevoli (escludiamo la possibilità di avere il database su macchine diverse dal server, come detto all'inizio), quando i dati cominciano ad essere complicati, il modello del vecchio database "a relazioni" non funziona poi tanto bene, o almeno diventa molto più complicato di costruirsi una sorta di mini-database interno a mano.
Enrico
Etichette: database, java, ottimizzazione, serializzazione
