web-dev-qa-db-fra.com

Comment dois-je nommer au mieux mes champs d'horodatage?

Lorsque je cherche à créer des champs d'horodatage (ou d'autres champs de style date/heure), quelle est la meilleure façon de les nommer? Dois-je simplement mettre record_timestamp?

naming-convention
61
garik

Vous devez décrire l'objectif de la colonne et pas nécessairement le type de données. Vous pouvez inclure la date/heure/horodatage dans le nom, mais vous devez également inclure la signification. Par exemple

  • Date de création
  • Date de début
  • StatusTime
  • Accédé
  • Mise à jour

L'ajout de Date/Heure/Horodatage et autres à la fin est particulièrement utile lorsque l'absence de l'addition entrerait en conflit avec une autre colonne. Par exemple, une table peut avoir besoin à la fois d'un statut et d'un statut.

44
Leigh Riffel

Que diriez-vous xyz_at pour un timestamp et xyz_on pour un champ date - par exemple start_at ou start_on?

Normalement, j'éviterais d'inclure le type de données dans le nom du champ - bien mieux si vous pouvez déduire ce que vous devez savoir sur le type à partir du nom d'un champ (un champ appelé description est peu susceptible d'être un integer) - mais être capable de faire la différence entre un timestamp et un date est souvent utile.

31
Jack says try topanswers.xyz

J'utilise:

  • créé à
  • updated_at
18
David LeBauer

J'ai regardé votre profil et il dit que vous travaillez avec SQL Server et dans SQL Server, le type de données TIMESTAMP n'a rien à voir avec la date ou l'heure et son type de version estampillé les lignes. Ceci est très utile pour identifier les lignes qui ont été modifiées à partir d'un moment donné.

Si vous utilisez TIMESTAMP, vous n'avez pas besoin de spécifier un nom de colonne et SQL Server créera une colonne "TimeStamp" pour vous. Mais il est recommandé d'utiliser le type de données "ROWVERSION" et dans ce cas, vous devez spécifier le nom de la colonne.

Quel est le meilleur nom pour une colonne comme celle-ci? Cela dépend, et j'utiliserais quelque chose comme VersionStamp, RV, etc. Ce que je considère important n'est PAS la façon dont vous le nommez mais l'utilisez-vous de manière cohérente dans tous les domaines.

HTH

Réf: http://msdn.Microsoft.com/en-us/library/ms182776 (v = sql.90) .aspx

http://msdn.Microsoft.com/en-us/library/ms182776.aspx

6
Sankar Reddy

J'ai constaté que l'utilisation de noms de colonnes tels que create_time, update_time et expire_time conduit à une meilleure lisibilité en matière de dénomination et de spécifications de méthode (RSpec).

3
Artur Beljajev

je préfère utiliser des conventions qui existent déjà.

Unix et les langages de programmation ont une convention largement acceptée de mtime pour Temps de modification

Pour le temps de création,

  • BSD et Windows utilisent l'heure de naissance
  • Windows utilise également le temps de création
  • xstat utilise btime
  • ext4 utilise crtime
  • JFS et btrfs utilisent otime (ne demandez pas, devinez "origine").

Donc pour moi, je choisis mtime et crtime pour les métadonnées.

Pour les données fournies par l'utilisateur, je choisis ce que le champ représente. Si c'est un anniversaire, je dis simplement user_birthday.

En ce qui concerne la précision, pour certains, cela semble les accrocher à trop de précision. Vous pouvez stocker votre birthdate sous forme d'horodatage (après tout, vous étiez techniquement né à une heure de la journée), mais la spécification SQL a des conversions de plus haute précision à une précision plus faible, donc si vous utilisez une base de données décente, cette ne devrait pas être un problème. Dans votre application elle-même, vous pouvez toujours tronquer en cas de besoin. C'est-à-dire que je n'irais jamais birthday_date.

2
Evan Carroll

Afin de maintenir la cohérence entre les noms de colonne, je vous suggère la syntaxe suivante:

dateCreated
dateUpdated
dateAccessed
dateStarted
date...
1
Andreas

Je préfère utiliser un préfixe DT pour les timbres à date. Par exemple: DTOpened, DTClosed, DTLastAccessed. Cela me permet de répertorier tous les DTxxxx pour une référence rapide de tous les timbres à date dans un tableau donné.

1
Michael Riley - AKA Gunny

Je travaille pour Texas Instruments, et sur leurs systèmes, ils utilisent xxxx _dttm

1
Barry McQuery

Comme le suggère @Evan Carroll, respectez les normes existantes, sauf si vous avez de bonnes raisons de casser le modèle.

Si c'est quelque chose de nouveau, vous pouvez suivre n'importe quelle réponse qui vous convient le mieux.

J'utilise * _on et * _by car cela m'aide à rester cohérent pour quand et qui de la ligne:

- created_on & created_by
- updated_on & updated_by
- deleted_on & deleted_by -- soft delete
- approved_on & approved_by
1
Shaunak Sontakke

Je voudrais utiliser un préfixe significatif et _TSMP comme suffixe, par exemple CREATION_TSMP ou LAST_UPDATE_TSMP

0
Paddy Carroll