20 Database migliori pratiche di progettazione

1. Utilizzare nomi ben definiti e coerenti per le tabelle e le colonne (ad esempio scuola, StudentCourse, CourseID ...).
2. Utilizzare singolare per i nomi delle tabelle (uso StudentCourse cioè invece di StudentCourses).Tabella rappresenta un insieme di entità, non vi è alcuna necessità di nomi plurali.
3. Non utilizzare spazi per i nomi di tabella. In caso contrario, si dovrà utilizzare '{', '[', '"', ecc caratteri per definire le tabelle (cioè per accesing Studente Corso di tabella si scrive" da studente ". StudentCourse è molto meglio).
4. Non utilizzare prefissi o suffissi non necessari per i nomi delle tabelle (Scuola uso cioè invece di TblSchool, SchoolTable ecc.)
5. Mantenere le password come criptate per la sicurezza. Decrypt in applicazione quando necessario.
6. Utilizzare i campi id interi per tutte le tabelle. Se id non è richiesto per il momento, si può esigere in futuro (per le tabelle di associazione, indicizzazione ...).
7. Scegli le colonne con tipo di dati integer (o le sue varianti) per l'indicizzazione. indicizzazione colonna varchar può causare problemi di prestazioni.
8. Utilizzare i campi di bit per i valori booleani. Utilizzando intero o varchar è inutilmente consumando memoria. Anche avviare i nomi di colonna con "è".
9. Fornire autenticazione per l'accesso al database. Non dare ruolo di amministratore per ogni utente.
10. Evitare di "SELECT *" query fino a quando non è realmente necessario. Utilizzare "selezionare [required_columns_list]" per migliorare le prestazioni.
11. Usare un ORM (Object Relational Mapping) quadro (cioè di sospensione, iBatis ...) se il codice dell'applicazione è abbastanza grande. Problemi relativi alle prestazioni dei quadri ORM può essere gestito da parametri di configurazione dettagliati.
12. Partizione più grande e non utilizzati / usato raramente tavoli / parti di tabella per diversi depositi fisici per migliorare le prestazioni delle query.
13. Per i sistemi critici grandi, sensibili e la missione di database, utilizzare il ripristino di emergenza e di sicurezza, come il clustering di failover, backup automatico, la replica ecc
14. Utilizzare i vincoli (chiave esterna, non controllare, null ...) per l'integrità dei dati. Non dare intero controllo al codice dell'applicazione.
15. La mancanza di documentazione del database è il male. Documentare la struttura del database con schemi ER e le istruzioni. Anche scrivere righe di commento per i tuoi trigger, stored procedure e altri script.
16. Utilizzare gli indici per le query di uso frequente su tavoli grandi. Analyser strumenti possono essere usati per determinare dove indici saranno definiti. Per le query recupero un intervallo di righe, gli indici cluster di solito sono migliori. Per le query punto, indici non cluster sono meglio.
17. Server di database e il server Web deve essere collocato in diverse macchine. Ciò fornirà una maggiore sicurezza (attaccanti non possono accedere ai dati direttamente) e al processore del server e le prestazioni della memoria sarà migliore a causa del ridotto numero di richiesta e l'utilizzo del processo.
18. Dati di immagine e blob colonne non devono essere definiti nelle tabelle spesso query a causa di problemi di prestazioni. Questi dati devono essere posti in tabelle separate e il puntatore può essere utilizzato in tabelle interrogate.
19. Normalizzazione deve essere utilizzato come richiesto, per ottimizzare le prestazioni. Under normalizzazione causerà la ripetizione eccessiva di dati, oltre alla normalizzazione causerà unisce eccessivo in troppi tavoli. Entrambi peggiorerà le prestazioni.
20. Trascorrere del tempo per la modellazione e la progettazione di database, per quanto richiesto. In caso contrario, salvato (!) Fase di progettazione causerà (salvato (!) Fase di progettazione) * Tempo di 10/100/1000 di manutenzione e re-design.