Speravo di ottenere un consiglio da voi gente sulle mie metodologie di progettazione delle tabelle (in particolare in MS SQL, se ciò fosse importante).
Vorrei iniziare mostrando un paio di tabelle di esempio che potrei avere in un'applicazione tipica:
EntityType
-----------
EntityTypeID int identity (PK)
Token varchar(10) (Nonclustered IDX, UNIQUE constraint)
Name varchar(50)
Description varchar(255)
Sequence int (default 100)
CreatedDate datetime
CreatedBy varchar(100)
DeactivatedDate datetime null
DeactivatedBy varchar(100) null
Entity
-----------
EntityID int identity (PK)
EntityTypeID int not null (FK to EntityType)
CreatedDate datetime
CreatedBy varchar(100)
DeactivatedDate datetime null
DeactivatedBy varchar(100) null
Person
----------
PersonID int identity (PK)
EntityID int (FK to Entity)
FirstName varchar(100)
LastName varchar(100)
CreatedDate datetime
CreatedBy varchar(100) [or possibly a FK to a UserID int, too]
DeactivatedDate datetime null
DeactivatedBy varchar(100) null
Fondamentalmente ho due tipi di "modelli" di tabelle (per modelli, intendo memoria muscolare nelle mie dita quando sto scrivendo istruzioni "CREATE").
Sono:
<TableName>ID int not null identity,
<Columns>,
CreatedDate datetime not null,
CreatedBy varchar(100),
DeactivatedDate datetime null,
DeactivatedBy varchar(100) null
E per alcune tabelle (principalmente tabelle di ricerca), l'aggiunta di una colonna "Token" e una "Sequence".
Note di colonna specifiche:
La colonna "Token" è così posso facilmente fare riferimento nel codice dell'applicazione (C #) con una chiave "named" anziché in un PK sequenziale che potrebbe essere diverso tra più istanze di database. Non sono stato troppo coerente qui, a volte userò i tipi CHAR, VARCHAR o UNIQUEIDENTIFIER. Quindi, se mai esiste una situazione in cui devo fare riferimento a un record specifico in appcode, non scriverei mai un hardcode su un PK, ma potrei hardcode (tramite codice o configurazione) un "token". I PK INT rimangono per i riferimenti FK e l'appcode automatico in cui non ho mai bisogno di hardcode qualcosa (come un elenco di record).
La colonna "Sequenza" è usata dai miei ORDER BY. Per esempio. %codice%. Se tutti i campi "Sequenza" sono gli stessi, che per impostazione predefinita saranno 100, verrà eseguito il fallback per l'ordinamento in base al Nome. Questo è utile per le tabelle come Paese in cui potremmo voler spostare "USA" in alto (ad esempio) ma mantenere tutto il resto ordinato in ordine alfabetico.
La colonna "DeactivatedDate" viene sempre utilizzata nelle query come un flag "IsActive" ( ORDER BY Sequence, Name ). Consente di registrare tracce di controllo o offre la possibilità di scadere di un record in un secondo momento.
Fondamentalmente: prima vengono le colonne usate come identificatori (PK, Token), tutte le altre colonne, e infine le restanti colonne "template" (la Sequence occasionale e praticamente sempre una sorta di colonne Audit per i dati creati / disattivati).
Ora che ti ho annoiato con tutto questo, le mie domande sono:
- È una buona metodologia di progettazione?
- Oppure esiste una metodologia di progettazione alternativa in cui posso scaricare alcune di queste colonne altrove, quindi non devo assicurarmi di nominare tutto correttamente (altrimenti il mio OCD si attiva e devo ripararlo a tutti i costi lol)
- È presente una colonna Token (chiave secondaria), pensata specificamente per le situazioni in cui il codice dell'app deve cercare o fare riferimento a un record specifico, una pratica comune?
- Esiste un nome migliore di "TOKEN"?
- Esiste un tipo di dati consigliato che dovrei rispettare per il token?
- Qualche altro suggerimento su come mantenere i dati di controllo e gestire i riferimenti a record specifici dall'appcode?
Grazie!