Suggerimenti per la progettazione di database di livello enterprise

Question

Io lavoro con un'applicazione aziendale ed ho raccolto alcuni suggerimenti per la progettazione di DB

1. Tutte le tabelle devono avere i seguenti campi che aiuta a audit trail - LastChangedBy, LastChanged, LastChangedPage
2. Tutte le stored procedure con SQL dinamico devono avere il parametro @bDebug. Per impostazione predefinita è impostato su 0. Se è impostato su 1, stampare l'istruzione SQL dinamica e ciò sarà molto utile nel debug.
3. Per CRUD SP, è possibile aggiornare parzialmente la tabella. Se la tua tabella ha 10 campi e in uno degli SP, ti interessa aggiornare solo 5 campi, avere un livello di astrazione per farlo.

Altri suggerimenti utili a cui si può pensare?

EDIT: Grazie per tutte le risposte. Sto ancora cercando una risposta che possa fornire un link a suggerimenti/trucchi/strategie per DB Design.

Answer 1

A mio parere uno richiederebbe CreatedBy e creati campi.

Answer 2

Per il n. 1: passare a SQL Server 2008 e attivare solo Change Data Capture. Se hai davvero bisogno di tenere traccia di audit dettagliati, questa funzione da sola giustificherà il costo.

Per # 2: Qualsiasi stored procedure con sql dinamico deve essere automaticamente inserita in doppia prova privata (ad esempio: è consentita, ma deve passare attraverso più livelli di revisione del codice per assicurarsi che non ci sia un modo migliore per farlo) .

Answer 3

Quando si tratta della potenza del Web, è meglio non cancellare mai nulla. Quindi avendo una data cancellata, puoi escludere solo quegli oggetti che sono stati "cancellati" dalle tue ricerche. Questo aiuta anche i clienti frenetici che hanno cancellato accidentalmente il loro account. Ovviamente questo non dovrebbe essere usato in ogni campo.

Answer 4

Un paio di pensieri che balzano subito in mente quando si lavora con database di grandi dimensioni (VLDB):

caso si sceglie di implementare il partizionamento delle tabelle?

Grandi tabelle di database, con milioni di record, possono trarre vantaggio dal partizionamento delle tabelle.

• La disponibilità di questo SQL Server caratteristica è costretti ad usare Enterprise Edition.
• L'applicabilità dipende dallo hardware della piattaforma e dalla disponibilità di una chiave di partizione appropriata all'interno dei dati della tabella.

Quali sono le tabelle con accesso più frequente?

Considerare la separazione per Filegroup, ad esempio posizionare la tabella Cliente su un Filegroup e su una tabella delle transazioni su un altro. Ciò consente a SQL Server di creare più thread per l'accesso ai file creando la possibilità di I/O sequenziali.

Successivamente, considerare la struttura del disco fisico sottostante, ovvero una LUN separata per ciascun filegroup.

Elaborare una strategia di indicizzazione flessibile

È senza dubbio già avere una strategia di indicizzazione in mente però per le piattaforme VLDB questo dovrebbe essere di frequente recensione. Man mano che aumentano i volumi di dati e la distribuzione dei dati cambia in modo che i piani di esecuzione per le query di accesso ai dati. Dovresti pianificare la necessità di rivedere regolarmente la tua strategia di indicizzazione.

Answer 5

LastChangedBy ecc. Campi sono piuttosto inutili. Se hai davvero bisogno di un audit trail, hai bisogno di tabelle di controllo separate che descrivono le modifiche e mantengono una cronologia di controllo. Se non hai bisogno di una pista di controllo, i campi LastChangedBy, ecc., Sono solo lavori aggiunti senza valore commerciale.

Answer 6

Le date devono essere archiviate nel formato Utc e convertite in ora locale sul client.