Bagaimana cara terbaik memberi nama bidang stempel waktu saya?


57

Ketika saya mencari untuk membuat beberapa bidang cap waktu (atau bidang gaya tanggal / waktu lainnya), apa cara terbaik untuk menamainya? Haruskah saya meletakkan record_timestamp?

Jawaban:


42

Anda harus menjelaskan tujuan kolom dan tidak harus tipe data. Anda dapat memasukkan tanggal / waktu / cap waktu dalam nama, tetapi Anda juga harus memasukkan artinya. Sebagai contoh

  • Tanggal Pembuatan
  • Mulai tanggal
  • StatusTime
  • Diakses
  • Diperbarui

Menambahkan Tanggal / Waktu / Stempel Waktu dan semacamnya pada akhirnya sangat berguna ketika absennya pertentangan akan bertentangan dengan kolom lain. Misalnya, tabel mungkin memerlukan Status dan StatusTime.


2
Hanya untuk menambahkan dua sen saya. Saya bekerja dengan banyak sistem MRP lama dan sering menemukan CreatedOnUtc dan UpdatedOnUtc.
Geovani Martinez

6
Saya pikir "Diakses" dan "Diperbarui" bisa ambigu, karena itu juga bisa menyiratkan boolean (setidaknya di dunia Ruby)
Artur Beljajev

2
@ GeovaniMartinez yang dapat membingungkan, seperti banyak database SQL, termasuk PostgreSQL, simpan di UTC dan baca di zona waktu klien.
Evan Carroll

Dan jika unit waktu seharusnya UTC vs Sistem Lokal maka tentukan _UTC dalam nama kolom. Terima kasih dari kita semua yang harus menjaga kode nanti.
Jonathan Fite

Diakses dan Diperbarui dapat menjadi ambigu dengan WHO yang diakses atau diperbarui, yang merupakan hal yang cukup umum untuk dilacak
Joe Phillips

27

Bagaimana dengan xyz_atuntuk timestampdan xyz_onuntuk datebidang - misalnya start_atatau start_on?

Biasanya saya akan menghindari memasukkan tipe data dalam nama bidang - jauh lebih baik jika Anda dapat menyimpulkan apa yang perlu Anda ketahui tentang jenis dari nama bidang apa pun (bidang yang disebut descriptiontidak mungkin menjadi integer) - tetapi bisa memberi tahu perbedaan antara a timestampdan a datesering kali membantu.


16

Saya menggunakan:

  • dibuat di
  • updated_at

2
"at" dapat menyiratkan lokasi juga. Bagaimana dengan "kapan" dan bukannya "pada"?
Sepster

1
"at" atau "as at" sering digunakan dalam dokumen hukum dan keuangan untuk merujuk ketika sesuatu terjadi. english.stackexchange.com/questions/112770/...
Neil McGuigan

3
Itu masih bisa ambigu. Bagaimana jika Anda perlu tahu waktu dan lokasi pembaruan? updated_atbisa juga. Tapi saya pikir jawabannya adalah, seperti biasa dengan penamaan, menggunakan nama paling ringkas yang menghilangkan semua ambiguitas realistis. Yaitu jika dalam konteks tertentu ada potensi untuk kebingungan tertentu, hilangkan itu, tetapi jangan menggunakan nama yang lebih bertele-tele daripada yang diperlukan untuk itu
nafg

1
bagaimana dengan "on". Meskipun ini menyiratkan kencan lebih dari satu waktu, itu masih cukup jelas
Joe Phillips

6

Saya melihat profil Anda dan mengatakan Anda bekerja dengan SQL Server dan dalam SQL Server TIMESTAMP tipe data tidak ada hubungannya dengan tanggal atau waktu dan digunakan untuk jenis versi yang menginjak baris. Ini sangat berguna dalam mengidentifikasi baris mana yang telah dimodifikasi dari titik waktu tertentu.

Jika Anda menggunakan TIMESTAMP maka Anda tidak perlu menentukan nama kolom dan SQL Server akan membuat kolom "TimeStamp" untuk Anda. Tetapi disarankan untuk menggunakan tipe data "ROWVERSION" dan dalam hal ini Anda harus menentukan nama kolom.

Apa nama terbaik untuk kolom seperti ini? Itu tergantung, dan saya akan menggunakan sesuatu seperti VersionStamp, RV dll ... Yang saya anggap penting BUKAN bagaimana Anda menyebutkannya tetapi apakah Anda menggunakannya secara konsisten.

HTH

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

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


3

Saya menemukan bahwa menggunakan nama kolom seperti create_time, update_timedan expire_timemengarah pada keterbacaan yang lebih baik ketika datang ke penamaan metode dan spesifikasi (RSpec).


1

Saya lebih suka menggunakan awalan DT untuk prangko tanggal. Sebagai contoh: DTOpened, DTClosed, DTLastAccessed. Ini memungkinkan saya daftar semua DTxxxx untuk referensi cepat dari semua perangko tanggal dalam tabel yang diberikan.


1

Saya bekerja untuk Texas Instruments, dan pada sistem mereka menggunakan xxxx_ dttm


1

Saya lebih suka menggunakan konvensi yang sudah ada.

Unix dan bahasa pemrograman memiliki konvensi yang diterima secara luas mtimeuntuk Waktu Modifikasi

Untuk waktu pembuatan,

  • BSD dan Windows menggunakan waktu lahir
  • Windows juga menggunakan Waktu Pembuatan
  • xstat menggunakan btime
  • penggunaan ext4 crtime
  • JFS dan btrfs gunakan otime(jangan tanya, tebak "originasi").

Jadi bagi saya, saya memilih mtime, dan crtimeuntuk data meta.

Untuk data yang diberikan pengguna, saya pergi dengan apa yang diwakili bidang tersebut. Jika ini hari ulang tahun, saya katakan saja user_birthday.

Sejauh presisi, untuk beberapa tampaknya menggantung terlalu banyak presisi. Anda dapat menyimpan Anda birthdatesebagai timestamp (setelah semua Anda secara teknis dilahirkan pada waktu hari), tetapi spesifikasi SQL telah dilemparkan dari presisi yang lebih tinggi ke presisi yang lebih rendah sehingga jika Anda menggunakan database yang layak ini seharusnya tidak menjadi masalah . Di aplikasi Anda sendiri, Anda selalu dapat memotong bila diperlukan. Artinya, saya tidak akan pernah pergi birthday_date.


0

Saya akan menggunakan awalan yang bermakna dan _TSMP sebagai akhiran misalnya CREATION_TSMP atau LAST_UPDATE_TSMP


0

Untuk menjaga konsistensi di antara nama kolom, saya sarankan Anda untuk sintaks berikut:

dateCreated
dateUpdated
dateAccessed
dateStarted
date...

0

Seperti yang disarankan oleh @Evan Carroll, gunakan standar yang ada kecuali Anda memiliki alasan kuat untuk menghentikan polanya.

Jika ini adalah sesuatu yang baru maka Anda dapat mengikuti jawaban apa pun yang paling cocok untuk Anda.

Saya menggunakan * _on dan * _by karena ini membantu saya untuk tetap konsisten untuk kapan dan siapa baris:

- created_on & created_by
- updated_on & updated_by
- deleted_on & deleted_by -- soft delete
- approved_on & approved_by
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.