Как мне лучше назвать свои поля меток времени?

Когда я пытаюсь создать несколько полей меток времени (или других полей стиля даты / времени), как лучше их назвать? Должен ли я просто поставить record_timestamp?

Вы должны описать назначение столбца, а не обязательно тип данных. Вы можете указать дату / время / метку времени в имени, но вы также должны включить значение. Например

• Дата создания
• Дата начала
• StatusTime
• Accessed
• обновленный

Добавление даты / времени / метки времени и т.п. в конце особенно полезно, когда отсутствие добавления будет конфликтовать с другим столбцом. Например, таблице может потребоваться как Status, так и StatusTime.

Как насчет xyz_atдля timestampи xyz_onдля dateполя - например, start_atили start_on?

Обычно я бы избегал включать тип данных в имя поля - гораздо лучше, если бы вы могли вывести то, что вам нужно знать о типе, по имени любого поля (поле, которое называется description, вряд ли будет integer), - но не могли бы сказать, разница между а timestampи а dateчасто бывает полезна.

Я использую:

• создано в
• updated_at

Я посмотрел на ваш профиль, и он говорит, что вы работаете с SQL Server, а в SQL Server тип данных TIMESTAMP не имеет ничего общего с датой или временем и используется для обозначения версий, помечающих строки. Это очень полезно при определении того, какие строки были изменены с данного момента времени.

Если вы используете TIMESTAMP, вам не нужно указывать имя столбца, а SQL Server создаст для вас столбец «TimeStamp». Но рекомендуется использовать тип данных «ROWVERSION», и в этом случае вы должны указать имя столбца.

Какое название для такой колонки лучше? Это зависит, и я бы использовал что-то вроде VersionStamp, RV и т. Д. Я считаю важным не то, как вы это называете, а то, используете ли вы это последовательно по всем направлениям.

НТН

Ссылка: http://msdn.microsoft.com/en-us/library/ms182776(v=sql.90).aspx

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

Я обнаружил, что использование имен столбцов, таких как create_time, update_timeи expire_timeприводит к лучшей читаемости, когда дело доходит до именования методов и спецификаций (RSpec).

Я предпочитаю использовать префикс DT для отметок даты. Например: DTOpened, DTClosed, DTLastAccessed. Это позволяет мне перечислить все DTxxxx для быстрого ознакомления со всеми отметками даты в данной таблице.

Я работаю в Texas Instruments, и в своих системах они используют xxxx_ dttm

Я предпочитаю использовать соглашения, которые уже существуют.

Unix и языки программирования имеют широко обслуживаемую конвенцию mtimeпо времени изменения

Для создания времени,

• BSD и Windows используют время рождения
• Windows также использует время создания
• Xstat использует btime
• Ext4 использует crtime
• JFS и btrfs используют otime(не спрашивайте, угадывая «происхождение»).

Так что для меня я выбираю mtimeи crtimeдля метаданных.

Для пользовательских данных, я иду с тем, что представляет поле. Если это день рождения, я просто говорю user_birthday.

Что касается точности, то для некоторых это кажется слишком высокой точностью. Вы можете сохранить свою birthdateметку времени (после того, как вы были технически рождены в определенное время суток), но спецификация SQL имеет преобразование с более высокой точности в более низкую, поэтому, если вы используете достойную базу данных, это не должно быть проблемой. , В самом приложении вы всегда можете обрезать при необходимости. То есть я бы никогда не пошел birthday_date.

Я бы использовал значимый префикс и _TSMP в качестве суффикса, например, CREATION_TSMP или LAST_UPDATE_TSMP

Чтобы обеспечить согласованность имен столбцов, я бы предложил следующий синтаксис:

dateCreated
dateUpdated
dateAccessed
dateStarted
date...

Как советует @Evan Carroll, придерживайтесь существующих стандартов, если у вас нет веских причин нарушать закономерность.

Если это что-то новое, тогда вы можете следовать любой ответ, который подходит вам лучше всего.

Я использую * _on и * _by, потому что это помогает мне поддерживать согласованность для того, когда и кто из ряда:

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