Ответы:
Вы должны описать назначение столбца, а не обязательно тип данных. Вы можете указать дату / время / метку времени в имени, но вы также должны включить значение. Например
Добавление даты / времени / метки времени и т.п. в конце особенно полезно, когда отсутствие добавления будет конфликтовать с другим столбцом. Например, таблице может потребоваться как 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
Я обнаружил, что использование имен столбцов, таких как create_time, update_timeи expire_timeприводит к лучшей читаемости, когда дело доходит до именования методов и спецификаций (RSpec).
Я предпочитаю использовать префикс DT для отметок даты. Например: DTOpened, DTClosed, DTLastAccessed. Это позволяет мне перечислить все DTxxxx для быстрого ознакомления со всеми отметками даты в данной таблице.
Я работаю в Texas Instruments, и в своих системах они используют xxxx_ dttm
Я предпочитаю использовать соглашения, которые уже существуют.
Unix и языки программирования имеют широко обслуживаемую конвенцию mtimeпо времени изменения
Для создания времени,
btimecrtimeotime(не спрашивайте, угадывая «происхождение»).Так что для меня я выбираю mtimeи crtimeдля метаданных.
Для пользовательских данных, я иду с тем, что представляет поле. Если это день рождения, я просто говорю user_birthday.
Что касается точности, то для некоторых это кажется слишком высокой точностью. Вы можете сохранить свою birthdateметку времени (после того, как вы были технически рождены в определенное время суток), но спецификация SQL имеет преобразование с более высокой точности в более низкую, поэтому, если вы используете достойную базу данных, это не должно быть проблемой. , В самом приложении вы всегда можете обрезать при необходимости. То есть я бы никогда не пошел birthday_date.
Я бы использовал значимый префикс и _TSMP в качестве суффикса, например, CREATION_TSMP или LAST_UPDATE_TSMP
Как советует @Evan Carroll, придерживайтесь существующих стандартов, если у вас нет веских причин нарушать закономерность.
Если это что-то новое, тогда вы можете следовать любой ответ, который подходит вам лучше всего.
Я использую * _on и * _by, потому что это помогает мне поддерживать согласованность для того, когда и кто из ряда:
- created_on & created_by
- updated_on & updated_by
- deleted_on & deleted_by -- soft delete
- approved_on & approved_by