venerdì 22 ottobre 2010

Come progettare un database.

Ieri sera, mentre ritornavo a casa in treno, mi ha colpito una situazione un po’ particolare.

Vedo un signore distinto, vestito bene, sui 40-45 anni, parlare col sul blackberry e diceva...”Si si, domattina appena arrivo in ufficio controllo nel mio schedario e le faccio sapere...”.

Sinceramente non so’ di cosa stavano parlando e di cosa doveva cercare nel suo schedario, ma la situazione che mi ha colpito è stato il fatto che una persona ancora mantiene uno schedario e non un database.

Eppure sapeva utilizzare bene il suo BB, cioè non era imbranato o impacciato nell’utilizzarlo e nonostante ciò aveva un suo “schedario”.

Se avesse avuto un DB, magari tramite il suo BB avrebbe dato subito la risposta che attendevano dall’altra parte del telefono.

Oramai esistono database adatti per ogni evenienza, anzi, con i nuovi smarthphone e per essere ancora più precisi con l’iPhone, esistono delle applicazioni che fanno interagire benissimo i database installati sui PC/MAC e il proprio smarthphone.

Immaginatevi una situazione come quella di ieri sera, dove eravate voi i protagonisti della telefonata.

Se fosse stata una situazione veramente importante in cui volevate una risposta immediata, vi avrebbe fatto piacere che magari il vs interlocutore vi dicesse...”Un attimo, controllo nel database e le dico immediatamente!”...quanto tempo si andava a risparmiare?

Progettare un buon DB significa andare a considerare soprattutto le situazioni critiche e di fornire i risultati della ricerca in tempi rapidissimi.

Oggi giorno abbiamo a che fare con una vita frenetica e abbiamo tutti bisogno di un apporto sempre costante di informazioni e pure nel minor tempo possibile.

Ricordatevi che più è semplice un database da utilizzare, intuitivo ecc. e meglio è. Quindi sforzatevi di entrare nella testa dell’utilizzatore finale e ponetevi le classica domanda “Se io dovessi utilizzarlo in una situazione del genere, cosa vorrei da questo prodotto?

E dunque, quando andate a progettare il vs database, o per voi stessi o per gli altri, la prima cosa da fare è quello di andare a considerare più situazioni possibili, in modo tale che chi utilizza il vostro database o gestionale o sistema informativo, non si trova nella situazione di stallo/blocco...o ancora peggio di una non risposta...perché non si era prevista.