20 best practice per progettare un database

Di seguito le 20 best practice su come progettare un database:

  1. Usa nomi di tabelle e di colonne ben definite e consistenti (e.g. Scuola, CorsoStudente, IDCorso, …).
  2. Usa il singolare per i nomi delle Entità (i.e. usa Scuola anziché Scuole), e il plurale per i nomi delle tabelle. Una tabella rappresenta un’entità che è una collezione di istanze o occorrenze (di scuole nell’esempio). Di regola l’entità va scritta al singolare mentre nessuno dice che debba essere usato il singolare per i nomi delle tabelle; ecco perché, in questo sito, si è scelto di scrivere i nomi delle tabelle al plurale a evidenziare che esse contengono un elenco di righe (ad esempio Scuole fa capire che la tabella contiene un elenco e non una sola scuola)
  3. Non usare spazi nei nomi delle tabelle. Altrimenti quando la tabella sarà inserita in un DBMS, sarai costretto a usare i caratteri ‘{‘, ‘[‘, ‘“’ etc. per definirle e per poi usarle ad esempio in una query.
  4. Non usare prefissi o suffissi per i nomi delle tabelle, n (i.e. usa Scuola anziché TabellaScuola o ElencoScuole: si sa che una tabella è un elenco).
  5. I campi che conservano password devono farlo in forma cifrata per sicurezza. Non solo non è necessario ma è completamente insicuro conservare password in chiaro; quando un utente inserisce la propria password in chiaro (nel proprio browser), poi la invia in forma cifrata: è questa la password che va confrontata con quella conservata (anch’essa cifrata)
  6. …ancora altre 5 regole per un buon database

  7. Scegli il tipo numerico (intero) per i campi identificativi in tutte le tabelle. Se vi sembra che l’id non sia necessario per il momento lo sarà di sicuro per il futuro (ad esempio per le associazioni o come indice).
  8. Scegli le colonne con tipo di dato intero (o sua variante) come colonne indice. Usare colonne di tipo varchar (o testuali) come indice crea problemi di performance.
  9. Usa campi di tipo bit per i valori booleani. Usare interi o varchar è un inutile spreco di spazio. (se si fa un database con nomi in inglese è buona norma far iniziare il nome del campo con: “Is”: i.e.: IsEnabled).
  10. Crea account utente per l’accesso al database. Non dare a tutti il ruolo di amministratore.
  11. Evita di fare query del tipo: “select *” tranne quando strettamente necessario. Usare “select [lista di colonne]” migliora le performance.
  12. …ancora altre 10 ma per adesso 5…

  13. Usa un framework ORM (object relational mapping) framework (i.e. hibernate, iBatis …) se il codice dell’applicazione è grande abbastanza. I problemi di performance dei framework ORM possono essere gestiti da opportuni parametri di configurazione
  14. Le tabelle grosse o non usate o usate raramente, possono essere suddivise in pezzi e memorizzate su differenti dispositivi di memorizzazione per avere migliori performance nelle query.
  15. Per database grandi, sensibili o “mission critic” usa dei servizi di sicurezza e disaster recovery come failover clustering, backup automatici, replication ecc.
  16. Usa i necessari vincoli di campo (foreign key, check, not null …) per controllare l’integrità dei dati. Meglio evitare che il controllo sulla correttezza dei dati inseriti sia interamente demandato al codice dell’applicazione
  17. La mancanza di documentazione è da evitare. Documenta la progettazione del tuo database tramite lo schema ER e lo schema logico. Scrivi anche linee di commento per i trigger, le stored procedure e gli altri script.
  18. …ultime 5

  19. Usa gli indici per le query lanciate di frequente su tabelle grandi. Esistono degli strumenti di analisi capaci di determinare dove definire gli indici. Per le query che restituiscono un insieme di righe compreso tra un limite superiore e uno inferiore (Range Query), gli indici clustered sono in genere migliori; viceversa le query non-clustered sono più adatte alle cosiddette point-query
  20. Il server di Database e il web server dovrebbero essere messi in macchine diverse. Questo assicura una maggiore sicurezza grazie al fatto che gli eventuali attacchi non avrebbero accesso diretto ai dati; inoltre la performance di CPU e memoria saranno migliorate dal ridotto numero di richieste e di processi attivi
  21. Le colonne contenenti Immagini e dati di un blog non devono essere definiti nelle tabelle oggetto di frequenti query; questo per evitare ovvi problemi di performance. Questo tipo di dati deve essere messo in tabelle separate e accedere ad essi tramite i puntatori quando sono le tabelle che li contengono sono oggetto di query
  22. Bisogna normalizzare correttamente le tabelle per ottimizzare le performance. Una sotto-normalizzazionecauserà ripetizioni di dati, la sovra-normalizzazione invece troppi join tra le tabelle. Entrambe peggioreranno la performance del database.
  23. Bisogna impiegare il tempo necessario per la progettazione e la modellazione del database, anzi un tempo superiore al necessario. Il tempo risparmiato a progettare (o modellare) causerà un tempo di mantenimento e riprogettazione 10/100/1000 volte superiore.

Questo articolo è stato liberamente tratto (e tradotto) da: JavaCodeGeekes.