Como devo nomear melhor meus campos de carimbo de data / hora?

57

Quando estou procurando criar alguns campos de carimbo de data / hora (ou outros campos de estilo de data / hora), qual é a melhor maneira de nomeá-los? Devo apenas colocar record_timestamp?

naming-convention garik
fonte

Respostas:

42

Você deve descrever o objetivo da coluna e não necessariamente o tipo de dados. Você pode incluir data / hora / carimbo de data / hora no nome, mas também deve incluir o significado. Por exemplo

  • Data de criação
  • Data de início
  • StatusTime
  • Acessado
  • Atualizada

Adicionar data / hora / carimbo de data e hora no final é particularmente útil quando a ausência da adição entra em conflito com outra coluna. Por exemplo, uma tabela pode precisar de um Status e um StatusTime.

Leigh Riffel
fonte
2
Só para adicionar meus dois centavos. Trabalhei com muitos sistemas MRP herdados e encontrei o CreatedOnUtc e o UpdatedOnUtc usados ​​com freqüência.
Geovani Martinez
6
Eu acho que "acessado" e "Atualizado" pode ser ambígua, uma vez que também pode implicar booleano (pelo menos em Ruby mundo)
Artur Beljajev
2
@GeovaniMartinez que pode ser confuso, como muitos bancos de dados SQL, incluindo o PostgreSQL, armazenar na UTC e ler no fuso horário do cliente.
Evan Carroll
E se a unidade de tempo deve ser UTC x Local do Sistema, especifique _UTC no nome da coluna. Obrigado a todos nós, que precisamos manter o código posteriormente.
Jonathan Fite
Acessados e atualizados poderia ser ambígua com a OMS acessado ou atualizado, que é uma coisa bastante comum para rastrear
Joe Phillips
27

Como cerca xyz_atde um timestampe xyz_onpara um datecampo - por exemplo, start_atou start_on?

Normalmente, eu evitaria incluir o tipo de dados no nome do campo - muito melhor se você puder inferir o que precisa saber sobre o tipo no nome de qualquer campo ( descriptioné improvável que um campo chamado seja um integer) - mas ser capaz de informar a diferença entre a timestampe a dategeralmente é útil.

Jack Douglas
fonte
16

Eu uso:

  • criado em
  • updated_at
David LeBauer
fonte
2
"at" também pode implicar localização. Que tal "quando" em vez de "em"?
Sepster
11
"at" ou "as at" é usado com frequência em documentos legais e financeiros para se referir a quando algo aconteceu. english.stackexchange.com/questions/112770/…
Neil McGuigan
3
Ainda pode ser ambíguo. E se você precisar saber a hora e o local em que foi atualizado? updated_atPoderia ser. Mas acho que a resposta é, como sempre na nomeação, usar o nome mais conciso que remove toda ambiguidade realista. Ou seja, se em um contexto particular há potencial para uma certa confusão, eliminá-lo, mas não use nomes que são mais detalhado do que é necessário para que
nafg
11
que tal "on". Embora isso implica uma data mais do que uma vez, ainda é bastante óbvio
Joe Phillips
6

Eu olhei para o seu perfil e ele diz que você trabalha com o SQL Server e no SQL Server o tipo de dados TIMESTAMP não tem nada a ver com data ou hora e é usado para o tipo de versão que carimba as linhas. Isso é muito útil para identificar quais linhas foram modificadas a partir de um determinado momento.

Se você usar o TIMESTAMP, não precisará especificar um nome de coluna e o SQL Server criará uma coluna "TimeStamp" para você. Mas é recomendável usar o tipo de dados "ROWVERSION" e, nesse caso, você deve especificar o nome da coluna.

Qual é o melhor nome para uma coluna como essa? Depende, e eu usaria algo como VersionStamp, RV etc ... O que eu considero importante NÃO é como você o nomeia, mas você está usando isso de forma consistente em todos os aspectos.

HTH

Ref: http://msdn.microsoft.com/en-us/library/ms182776(v=sql.90).aspx

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

Sankar Reddy
fonte
3

Descobri que o uso de nomes de colunas como create_time, update_timee expire_timeleva a uma melhor legibilidade quando se trata de nomeação e especificações de métodos (RSpec).

Artur Beljajev
fonte
1

Prefiro usar um prefixo de DT para carimbos de data. Por exemplo: DTOpened, DTClosed, DTLastAccessed. Isso permite listar todos os DTxxxx para uma referência rápida de todos os carimbos de data em uma determinada tabela.

Michael Riley - também conhecido por Gunny
fonte
1

Eu trabalho na Texas Instruments, e em seus sistemas eles usam xxxx_ dttm

Barry McQuery
fonte
1

Eu prefiro usar convenções que já existem.

As linguagens de programação e Unix têm uma convenção amplamente aceita mtimepara o horário de modificação

Para a hora da criação,

  • BSD e Windows usam nascimento
  • O Windows também usa o Tempo de criação
  • xstat usa btime
  • usa ext4 crtime
  • JFS e btrfs usam otime(não pergunte, adivinhando "origem").

Então, para mim, eu escolho mtimee crtimepara metadados.

Para dados fornecidos pelo usuário, eu vou com o que o campo representa. Se é um aniversário, eu apenas digo user_birthday.

No que diz respeito à precisão, para alguns, parece pendurá-los com muita precisão. Você pode armazenar o seu birthdatecomo um carimbo de data / hora (afinal, você nasceu tecnicamente a uma hora do dia), mas as especificações SQL transmitem de maior precisão para menor precisão; portanto, se você estiver usando um banco de dados decente, isso não deve ser um problema. . No próprio aplicativo, você sempre pode truncar quando necessário. Ou seja, eu nunca iria birthday_date.

Evan Carroll
fonte
0

Eu usaria um prefixo significativo e _TSMP como sufixo, por exemplo, CREATION_TSMP ou LAST_UPDATE_TSMP

Paddy Carroll
fonte
0

Para manter a consistência entre os nomes das colunas, sugiro a seguinte sintaxe:

dateCreated
dateUpdated
dateAccessed
dateStarted
date...
Andreas
fonte
0

Conforme sugerido por @Evan Carroll, siga os padrões existentes, a menos que você tenha motivos fortes para quebrar esse padrão.

Se isso é algo novo, você pode seguir qualquer resposta que melhor lhe convier.

Eu uso * _on e * _by porque isso me ajuda a mantê-lo consistente para quando e quem da linha:

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