I fogli di calcolo – Excel, Fogli Google o un foglio con qualsiasi altro nome – sono strumenti davvero interessanti e potenti. Ma lo sono anche i database. Quando dovresti restare con un foglio di calcolo? Quando dovresti passare a un database?
Questa è la continuazione del mio precedente articolo "Fogli di calcolo e database:è ora di cambiare?" dove abbiamo discusso gli svantaggi più comuni dell'utilizzo di fogli di calcolo per organizzare molti dati. In questo articolo scopriremo come un database risolve questi problemi.
Utilizzo di un database per organizzare i dati
Il mio motto è “usa la tecnologia adeguata alle tue esigenze”. Se puoi gestire la tua attività tramite fogli, fantastico! Se hai bisogno di un semplice database, MS Access non è una cattiva opzione. Ma se questi prodotti non funzionano per te, probabilmente avrai bisogno di un database personalizzato e di un'applicazione web. Il database memorizzerà i tuoi dati; l'app Web sarà un modo intuitivo per interagire con il database e comunicare con il livello dati.
La nostra attività di servizi fittizia non era molto complicata, quindi potevamo alimentarla utilizzando un modello di dati abbastanza semplice. Se guardi l'immagine qui sotto, vedrai che tutto ciò di cui abbiamo bisogno è archiviato in sole cinque tabelle:client_type , client , service , replacement e has_service .
Una regola fondamentale per la progettazione del database è quella di conservare i dati relativi al mondo reale in un unico posto . In questo caso, manterremo tutti i nostri client dati nella tabella client. In questo modo, eviteremo di archiviare gli stessi dati in più posizioni (il cattivo tipo di ridondanza menzionato in precedenza). Se cambiamo qualcosa relativo a un cliente, lo faremo solo una volta, in questa tabella. Ciò migliorerà notevolmente la qualità dei dati e sarà positivo per le prestazioni.
La tabella successiva che contiene i dati del mondo reale è il service tavolo. Anche in questo caso, possiamo memorizzare qui tutti i dettagli relativi ai nostri servizi e possiamo apportare modifiche ai dati in modo abbastanza efficiente.
Il client tavolo e il service table sono entità del mondo reale che potrebbero esistere senza l'altra. Tuttavia, creare un database con entità non correlate non ha molto senso:è come avere clienti senza prodotti o servizi senza acquirenti. Quindi metteremo in relazione queste due tabelle usando has_service tavolo. Per archiviare informazioni su quali client hanno quale servizio, utilizzeremo chiavi esterne che fungono da riferimenti a quel client e servizio. Queste chiavi esterne puntano ai record nelle tabelle del servizio e del client. Possiamo anche conservare qualsiasi informazione aggiuntiva relativa a ciascun rapporto cliente-servizio in questa tabella.
Il client_type table è usato come un dizionario che memorizza ogni possibile tipo di client. È meglio mantenere diverse segmentazioni in tabelle del dizionario separate (ad esempio, se avessimo tipi di clienti e tipi di ruolo dei dipendenti, li memorizzeremmo in tabelle diverse). Tuttavia, abbiamo solo bisogno di una tabella perché questo è un modello semplice.
L'ultima tabella nel nostro modello è la replacement tavolo. Lo useremo per mettere in relazione due servizi:un servizio che vogliamo sostituire e il servizio di sostituzione. Questo ci dà la flessibilità di offrire ai clienti la sostituzione dei servizi esistenti (molto simile al passaggio da un piano di telefonia mobile a un altro).
Vantaggi del database
I database sono più complicati da configurare rispetto ai fogli di calcolo, ma questo in realtà offre loro alcuni vantaggi significativi in termini di integrità e sicurezza dei dati:
Chiavi e vincoli
I database dispongono di regole e controlli integrati che, se utilizzati correttamente, prevengono la maggior parte dei problemi di qualità e prestazioni dei dati. Le chiavi primarie (colonne che identificano in modo univoco ogni record in una tabella) e le chiavi esterne (colonne che fanno riferimento a un record in un'altra tabella) sono fondamentali per la sicurezza dei dati, ma la definizione di chiavi alternative o UNICHE (che contengono dati univoci per ciascun record in una tabella ) è anche molto utile.
Nei database relazionali, le chiavi mettono in relazione i dati di tabelle diverse. La chiave primaria della tabella è sempre UNICA, mentre una chiave esterna fa riferimento alla chiave primaria di un'altra tabella. Tale riferimento mette in relazione i dati di queste due tabelle (ad es. le chiavi esterne nel has_service tabella mette in relazione i dati dei clienti con i servizi di cui dispone). Ci avviserà anche se stiamo per eliminare una chiave primaria a cui si fa riferimento in qualche altra tabella. Questo ci impedirà di eliminare i record che sono ancora necessari (come riferimenti) in un'altra tabella.
I vincoli definiscono il tipo di dati che possono essere inseriti in un campo. Possiamo specificare che i dati devono avere valore (NON NULL), definire un formato per i numeri di telefono, contenere solo lettere e così via. Ciò significa che possiamo evitare problemi con i dati causati da persone che inseriscono il tipo sbagliato di dati in un campo.
Sicurezza e autorizzazioni
Un'altra caratteristica molto importante del database è il controllo dell'accesso ai tuoi dati . Ciò ti dà la possibilità di impostare non solo chi può accedere al tuo database, ma anche di controllare ciò che può vedere o modificare. Questa è una parte enorme della sicurezza dei dati. Ad esempio, è possibile definire un ruolo utente che consenta a un dipendente di modificare i dettagli del cliente ma non i dettagli del servizio. Puoi anche impostare regole su cui i dipendenti possono modificare o eliminare i dati. È buona norma assicurarsi che le persone abbiano accesso solo ai dati di cui hanno bisogno per svolgere il proprio lavoro.
Certo, potremmo provare a ricreare queste funzionalità in fogli (almeno in qualche modo), ma sarebbe sicuramente "reinventare la ruota".
Non potremmo semplicemente usare un foglio di calcolo?
Certo che potremmo. Potremmo creare fogli che seguono lo stesso schema utilizzato nel modello dati. Ciò risolverebbe molti problemi relativi ai dati, ma...
La replica del modello di dati in fogli non è sicuramente un'opzione ideale. Perderemmo tutti i vantaggi che il sistema di database ci offre, tutte le regole e i vincoli che mantengono i dati "sani", tutte le cose che impediscono cancellazioni accidentali e altri errori. Perderemmo l'ottimizzazione e, se il set di dati fosse abbastanza grande, le prestazioni subirebbero un duro colpo.
Anche se l'abbiamo risolto, che dire della condivisione dei dati, ad es. avere più utenti che utilizzano lo stesso foglio contemporaneamente? Quali problemi di integrità dei dati e prestazioni potrebbero causare? Questo sarebbe l'opposto di mantenere le cose semplici.
Quindi, se ritieni che i fogli non possano gestire le tue esigenze aziendali, probabilmente sei già diretto verso un database. Se ti trovi bloccato con i dati archiviati nei fogli e desideri spostarti in un database, dovresti:
- Crea un modello di database che memorizzi i tuoi dati in modo ottimale.
- Crea un'applicazione con il database in background.
- Cancella i tuoi dati, trasformali (se necessario) e importali nel database.
- Continua a lavorare solo con il database.
Quale dovresti scegliere:foglio di calcolo o database?
Nell'articolo di oggi, abbiamo imparato come un database risolve i problemi con l'utilizzo di fogli per organizzare molti dati. Il mio consiglio è sempre con la soluzione più semplice al tuo problema . Se i fogli di calcolo faranno il lavoro correttamente, usali. Ma se sei un'azienda basata sui dati, dovresti iniziare a utilizzare un database il prima possibile. Più a lungo aspetti per pulire e migrare i tuoi dati, più doloroso sarà il processo.
