Best Practices: nominare i campi in un database

Può sembrare di poca importanza, in realtà nominare i campi in un database quando si creano tabelle è un’operazione fondamentale. Moltissimi oggetti sono basati sulle tabelle: query, maschere, report; anche il codice VBA spesso fa riferimento ai campi contenuti nelle tabelle. Dare il nome giusto in fase di creazione della tabella è molto importante.

Una delle norme fondamentali nella progettazione di un database è che non esistono due campi che abbiano lo stesso nome all’interno del database, a meno che si tratti dei campi chiave primaria / chiave esterna. Si viola questa norma tipicamente quando i campi chiave primaria si chiamano tutti “ID”. Talvolta può derivare dal fatto che è stato Microsoft Access ad aggiungere il campo alla nostra tabella e lo ha nominato ID… ma allora direi subito: come hai potuto pensare di progettare una tabella senza chiave primaria?! Tieni presente che ci sono situazioni in cui senza una chiave primaria è impossibile eliminare un record (perché non c’è possibilità di identificarlo in modo univoco, scopo appunto della chiave primaria).
L’idea è molto semplice: se hai due campi con lo stesso nome significa che contengono lo stesso dato (e può accadere solo per chiave primaria / chiave esterna, altrimenti stai memorizzando due volte lo stesso dato ed è un problema di progettazione). Se i dati sono diversi e i nomi sono uguali, allora devi modificare i nomi dei campi: stai cominciando a fare confusione e la strada per realizzare un database è lunga. Correggi subito!

Schema relazioni database

Nella figura gli unici campi ripetuti sono quelli chiave primaria e chiave esterna, evidenziati in giallo.

Anche nel caso degli oggetti di un database si possono seguire alcune consuetudini.
Le tabelle contengono più record, perciò hanno un nome plurale, preferibilmente con un prefisso che le identifichi come tali, tbl. Se ho una tabella di individui, potrei chiamarla tblIndividui. L’utilità del prefisso è che ci sono alcune situazioni, quando si creano controlli sulle maschere, per esempio, in cui Microsoft Access riepiloga in un elenco sia tabelle sia query, senza raggrupparle per tipologia di oggetto. Con il prefisso tbl avremo in ordine e vicine tra loro tutte le tabelle.

Le query possono essre di vario tipo. Un’idea può essere di usare un prefisso che identifichi la tipologia di query: sel (select) per le query di selezione, mkt (make table) per le query di creazione tabelle, upd (update) per quelle di aggiornamento. Così facendo, avremo vicine e in ordine tra loro tutte le nostre query.

Nel caso delle maschere, se il mio database contiene anche sottomaschere, possiamo usare come prefisso s (sub). Per esempio una sottomaschera che visualizza le fatture nella maschera Clienti potrebbe chiamarsi sFatture. In tal modo, al crescere del numero di maschere nel mio database, riesco sempre a distinguere facilmente le maschere dalle sottomaschere.

La stessa logica nella nomenclatura delle maschere può essere usata per i report.

Un database è uno strumento che aiuta a gestire i dati: più siamo ordinati nella progettazione e nella realizzazione del nostro gestionale, più il risultato sarà di qualità: l’ordine chiama l’ordine…

A proposito di Best Practices, guarda il video del canale formazione su youtube e impara a evitare errori nella progettazione di una tabella.