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

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

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

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

Que tal xyz_atpara 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 a partir do nome de qualquer campo ( descriptioné improvável que um campo chamado seja um integer) - mas ser capaz de dizer a diferença entre a timestampe a dateé frequentemente útil.

Eu uso:

• criado em
• atualizado_at

create_timeDescobri que usar nomes de coluna como update_timee expire_timeleva a uma melhor legibilidade quando se trata de nomenclatura e especificações de métodos (RSpec).

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

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

Qual é o melhor nome para uma coluna como esta? Depende, e eu usaria algo como VersionStamp, RV etc.

HTH

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

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

Não existe uma maneira exata de fazer isso, a única coisa importante é ser consistente em sua base de código e bancos de dados para que os desenvolvedores não fiquem confusos.

A nomenclatura exata depende das convenções de idioma, mas eu escolheria uma das seguintes opções abaixo:

Python, Java, ORACLE/Postgresql

created_at, createdAt, CREATED_AT // Time when the record was created
updated_at, updatedAt, UPDATED_AT // Time when the record was last modified
started_at, startedAt, STARTED_AT // Some other record time

Or

create_time, createTime, CREATE_TIME
update_time, updateTime, UPDATE_TIME
start_time, startTime, START_TIME

Praticamente todos os campos são armazenados como timestamp, haverá alguns campos obrigatórios como data, mas geralmente eles estão mais relacionados ao domínio da empresa e podem ser nomeados de acordo com a próxima solicitação

• aniversário
• realase_date
• dia de negócios

Todos os campos de carimbo de data/hora a serem armazenados em UTC.

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

As linguagens Unix e de programação têm uma convenção amplamente aceita de Tempo mtimede Modificação

Para o tempo de criação,

• BSD e Windows usam hora de nascimento
• O Windows também usa o Tempo de Criação
• xstat usabtime
• ext4 usacrtime
• 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, 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 em muita precisão. Você pode armazenar seu birthdatecomo um carimbo de data/hora (afinal, você nasceu tecnicamente em uma hora do dia), mas a especificação SQL foi convertida de alta precisão para menor precisão, portanto, se você estiver usando um banco de dados decente, isso não deve ser um problema . Em seu próprio aplicativo, você sempre pode truncar quando necessário. Ou seja, eu nunca iria birthday_date.

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

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

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

dateCreated
dateUpdated
dateAccessed
dateStarted
date...