Як мені найкраще назвати поля часової позначки?

57

Коли я шукаю створити кілька полів часових позначок (або інших полів стилю дати / часу), який найкращий спосіб назвати їх? Потрібно просто поставити record_timestamp?

naming-convention 
— гарік
джерело

Відповіді:

42

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

  • Дата створення
  • Дата початку
  • StatusTime
  • Доступний
  • Оновлено

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

— Лей Ріффель
джерело
2
Тільки щоб додати мої два центи. Я працював із багатьма застарілими системами MRP і виявив, що часто використовуються CreateOnUtc та UpdateOnUtc.
— Геовані Мартінес
6
Я думаю, що "Доступ" та "Оновлено" можуть бути неоднозначними, оскільки це також може означати булевий характер (принаймні у світі Рубі)
— Артур Беляєв
2
@GeovaniMartinez, що може збивати з пантелику, оскільки безліч баз даних SQL включає PostgreSQL, зберігати в UTC та читати у часовому поясі клієнта.
— Еван Керролл
І якщо одиниця часу має бути UTC та System Local, тоді в назві стовпця вкажіть _UTC. Дякую від усіх нас, хто повинен підтримувати код пізніше.
— Джонатан Фійт
Доступ та оновлення може бути неоднозначним із доступом до ВООЗ або оновленням, що слід відстежувати
— Джо Філліпс
27

Як щодо xyz_atдля timestampі xyz_onдля dateполя - наприклад , start_atабо start_on?

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

— Джек Дуглас
джерело
16

Я використовую:

  • created_at
  • updated_at
— Девід Лебоуер
джерело
2
"at" також може означати розташування. Що з "коли" замість "у"?
— Сепстер
1
"at" або "as at" часто використовується в юридичних та фінансових документах для посилання на те, коли щось сталося. english.stackexchange.com/questions/112770/…
— Neil McGuigan
3
Це все ще може бути неоднозначним. Що робити, якщо вам потрібно знати час та місце, де оновлено оновлення? updated_atможе бути будь-який. Але я думаю, що у відповіді, як завжди при називанні, використовуйте найбільш стисле ім’я, яке усуває всю реалістичну неоднозначність. Тобто, якщо в конкретному контексті є певна плутанина, усуньте її, але не використовуйте імена, які є більш багатослівними, ніж це потрібно для цього
— nafg
1
як щодо "на". Хоча це передбачає побачення більше часу, це все ще досить очевидно
— Джо Філіпс
6

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

Якщо ви використовуєте TIMESTAMP, вам не потрібно вказувати ім’я стовпця, і SQL Server створить колонку "TimeStamp" для вас. Але рекомендується використовувати тип даних "ROWVERSION", і в цьому випадку потрібно вказати назву стовпця.

Яке найкраще ім’я для такої колонки? Це залежить, і я б використовував щось на зразок VersionStamp, RV тощо ... Що я вважаю важливим, це НЕ, як ви його називаєте, а чи використовуєте ви це послідовно в усьому світі.

HTH

Посилання: http://msdn.microsoft.com/en-us/library/ms182776(v=sql.90).aspx

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

— Санкар Редді
джерело
3

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

— Артур Беляєв
джерело
1

Я вважаю за краще використовувати префікс DT для штампів дати. Наприклад: DTOpened, DTClosed, DTLastAccessed. Це дозволяє мені перерахувати всі DTxxxx для швидкого ознайомлення з усіма марками дати в даній таблиці.

— Майкл Райлі - AKA Gunny
джерело
1

Я вважаю за краще використовувати конвенції, які вже існують.

У Unix та мовах програмування є широко прийнята конвенція mtimeдля модифікації часу

На час створення,

  • BSD і Windows використовують час народження
  • Windows також використовує час створення
  • xstat використовує btime
  • ext4 використовує crtime
  • JFS та btrfs використовують otime(не запитуйте, вгадавши "походження").

Тож для мене я підбираю mtimeі crtimeмета-дані.

Для даних, що надаються користувачем, я переглядаю те, що представляє поле. Якщо це день народження, я просто кажу user_birthday.

Що стосується точності, для деяких, здається, підвішують їх на занадто велику точність. Ви можете зберігати свою birthdateпозначку як часову позначку (зрештою, технічно ви робили час доби), але специфікація SQL має відмінність від більш точної до нижчої точності, тому якщо ви використовуєте гідну базу даних, це не повинно бути проблемою. . У самому додатку ви завжди можете усікати, коли потрібно. Тобто я ніколи не пішов би birthday_date.

— Еван Керролл
джерело
0

Щоб зберегти узгодженість імен стовпців, я б запропонував вам наступний синтаксис:

dateCreated
dateUpdated
dateAccessed
dateStarted
date...
— Андреас
джерело
0

Як пропонує @Evan Carroll, дотримуйтесь існуючих стандартів, якщо у вас немає вагомих причин зламати схему.

Якщо це щось нове, то ви можете слідувати будь-якій відповіді, яка вам найбільше підходить.

Я використовую * _on та * _by, тому що це допомагає мені підтримувати відповідність коли та кому з рядків:

- created_on & created_by
- updated_on & updated_by
- deleted_on & deleted_by -- soft delete
- approved_on & approved_by
— Шаунак Сонтакке
джерело
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.