Risposte:
Dovresti descrivere lo scopo della colonna e non necessariamente il tipo di dati. Puoi includere data / ora / data / ora nel nome, ma dovresti anche includerne il significato. Per esempio
L'aggiunta di Data / Ora / Timestamp e simili alla fine è particolarmente utile quando l'assenza dell'aggiunta sarebbe in conflitto con un'altra colonna. Ad esempio, una tabella potrebbe richiedere sia uno Status sia uno StatusTime.
Che ne dici xyz_atdi un timestampe xyz_onper un datecampo - ad es. start_atO start_on?
Normalmente eviterei di includere il tipo di dati nel nome del campo - molto meglio se puoi dedurre ciò che devi sapere sul tipo dal nome di qualsiasi campo ( descriptionè improbabile che un campo chiamato sia un integer) - ma potrei dire la differenza tra a timestampe a dateè spesso utile.
Io uso:
updated_atpotrebbe essere neanche. Ma penso che la risposta sia, come sempre con la denominazione, utilizzare il nome più conciso che rimuove tutta l'ambiguità realistica. Vale a dire se in un particolare contesto esiste il potenziale per una certa confusione, eliminarla, ma non usare nomi più prolissi di quanto richiesto per quello
Ho esaminato il tuo profilo e mi dice che lavori con SQL Server e in SQL Server il tipo di dati TIMESTAMP non ha nulla a che fare con la data o l'ora e viene utilizzato per il tipo di versione che timbra le righe. Questo è molto utile per identificare quali righe sono state modificate da un determinato momento.
Se si utilizza TIMESTAMP, non è necessario specificare un nome di colonna e SQL Server creerà una colonna "TimeStamp" per te. Ma si consiglia di utilizzare il tipo di dati "ROWVERSION" e in questo caso è necessario specificare il nome della colonna.
Qual è il nome migliore per una colonna come questa? Dipende, e userei qualcosa come VersionStamp, RV ecc ... Quello che considero importante NON è come lo chiami, ma lo stai usando in modo coerente su tutta la linea.
HTH
Rif: http://msdn.microsoft.com/en-us/library/ms182776(v=sql.90).aspx
Ho scoperto che l'uso di nomi di colonna come create_time, update_timee expire_timeporta a una migliore leggibilità quando si tratta di denominazione e specifiche dei metodi (RSpec).
Preferisco usare un prefisso di DT per i timbri data. Ad esempio: DTOpened, DTClosed, DTLastAccessed. Questo mi consente di elencare tutti i DTxxxx per un rapido riferimento di tutti i timbri data in una determinata tabella.
Lavoro per Texas Instruments e sui loro sistemi usano xxxx_ dttm
Preferisco usare convenzioni già esistenti.
Unix e linguaggi di programmazione hanno una convenzione ampiamente accettata mtimeper il Tempo di modifica
Per il momento della creazione,
btimecrtimeotime(non chiedere, indovinando "origine").Quindi, per me, scelgo mtimee crtimeper i metadati.
Per i dati forniti dall'utente, vado con ciò che il campo rappresenta. Se è un compleanno, dico solo user_birthday.
Per quanto riguarda la precisione, per alcuni sembra appenderli a troppa precisione. Puoi archiviarlo birthdatecome un timestamp (dopo tutto quello che sei nato tecnicamente in un momento della giornata), ma le specifiche SQL hanno cast da una maggiore precisione a una minore precisione, quindi se stai usando un database decente questo non dovrebbe essere un problema . Nella tua stessa app, puoi sempre troncare quando necessario. Vale a dire, non ci andrei mai birthday_date.
Vorrei utilizzare un prefisso significativo e _TSMP come suffisso, ad esempio CREATION_TSMP o LAST_UPDATE_TSMP
Come suggerito da @Evan Carroll, segui gli standard esistenti a meno che tu non abbia validi motivi per interrompere il modello.
Se si tratta di qualcosa di nuovo, puoi seguire qualsiasi risposta più adatta a te.
Uso * _on e * _by perché mi aiuta a mantenerlo coerente per quando e chi della riga:
- created_on & created_by
- updated_on & updated_by
- deleted_on & deleted_by -- soft delete
- approved_on & approved_by