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

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