ฉันจะตั้งชื่อช่องเวลาที่ดีที่สุดได้อย่างไร


57

เมื่อฉันต้องการสร้างเขตข้อมูลบันทึกเวลา (หรือเขตข้อมูลสไตล์วันที่ / เวลา) เป็นวิธีที่ดีที่สุดในการตั้งชื่อเขตข้อมูลเหล่านั้นคืออะไร ฉันควรใส่ record_timestamp หรือไม่

คำตอบ:


42

คุณควรอธิบายวัตถุประสงค์ของคอลัมน์และไม่จำเป็นต้องเป็นประเภทข้อมูล คุณสามารถรวมวันที่ / เวลา / เวลาประทับในชื่อได้ แต่คุณควรระบุความหมายด้วย ตัวอย่างเช่น

  • วันที่สร้าง
  • วันที่เริ่มต้น
  • StatusTime
  • เข้าถึงได้
  • Updated

การเพิ่มวันที่ / เวลา / เวลาประทับและท้ายที่สุดจะมีประโยชน์อย่างยิ่งเมื่อความไม่ชัดเจนของการเพิ่มจะขัดแย้งกับคอลัมน์อื่น ตัวอย่างเช่นตารางอาจต้องมีทั้งสถานะและ StatusTime


2
เพียงเพื่อเพิ่มสองเซ็นต์ของฉัน ฉันทำงานกับระบบ MRP รุ่นเก่าและพบว่า CreatedOnUtc และ UpdatedOnUtc ใช้บ่อย
Geovani Martinez

6
ฉันคิดว่า "เข้าถึง" และ "อัปเดต" อาจคลุมเครือเนื่องจากยังสามารถบ่งบอกถึงบูลีน (อย่างน้อยในโลก Ruby)
Artur Beljajev

2
@GeovaniMartinez ที่อาจสร้างความสับสนเนื่องจากฐานข้อมูล SQL จำนวนมากรวม PostgreSQL ไว้ที่ UTC และอ่านในเขตเวลาของลูกค้า
Evan Carroll

และถ้าหน่วยเวลาควรเป็น UTC กับ System Local ให้ระบุ _UTC ในชื่อคอลัมน์ ขอขอบคุณจากพวกเราทุกคนที่ต้องรักษารหัสไว้ในภายหลัง
Jonathan Fite

การเข้าถึงและอัปเดตอาจคลุมเครือกับการเข้าถึงหรืออัปเดตของ WHO ซึ่งเป็นสิ่งที่พบได้ทั่วไปในการติดตาม
Joe Phillips

27

วิธีการเกี่ยวกับxyz_atหาtimestampและxyz_onหาdateข้อมูล - เช่นstart_atหรือstart_on?

โดยปกติฉันจะหลีกเลี่ยงการรวมประเภทข้อมูลในชื่อฟิลด์ - ดีกว่ามากถ้าคุณสามารถอนุมานสิ่งที่คุณต้องรู้เกี่ยวกับประเภทจากชื่อของฟิลด์ใด ๆ (ฟิลด์ที่เรียกว่าdescriptionไม่น่าจะเป็นinteger) - แต่สามารถบอกได้ ความแตกต่างระหว่าง a timestampและ a dateมักเป็นประโยชน์


16

ฉันใช้:

  • created_at
  • updated_at

2
"ที่" สามารถระบุตำแหน่งได้เช่นกัน สิ่งที่เกี่ยวกับ "เมื่อ" แทนที่จะเป็น "ที่"?
Sepster

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

Ref: 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 ทั้งหมดสำหรับการอ้างอิงอย่างรวดเร็วของการประทับวันที่ทั้งหมดในตารางที่กำหนด



1

ฉันชอบใช้การประชุมที่มีอยู่แล้ว

Unix และการเขียนโปรแกรมภาษามีการประชุมกันอย่างแพร่หลายเป็นที่ยอมรับของmtimeสำหรับการปรับเปลี่ยนเวลา

สำหรับการสร้างเวลา

  • BSD และ Windows ใช้เวลาเกิด
  • Windows ยังใช้เวลาสร้าง
  • xstat ใช้ btime
  • การใช้งาน ext4 crtime
  • JFS และ btrfs ใช้งานotime(ไม่ต้องถามเดา "การกำเนิด")

ดังนั้นสำหรับฉันฉันเลือกmtimeและcrtimeสำหรับข้อมูลเมตา

สำหรับข้อมูลที่ผู้ใช้ให้ฉันไปกับสิ่งที่สนามแสดง user_birthdayถ้ามันเป็นวันเกิดของผมเพียงแค่พูดว่า

เท่าที่มีความแม่นยำสำหรับบางคนดูเหมือนว่าพวกเขาวางบนความแม่นยำมากเกินไป คุณสามารถจัดเก็บของคุณbirthdateเป็นเวลา (หลังจากทั้งหมดที่คุณเกิดทางเทคนิคในช่วงเวลาของวัน) แต่ข้อมูลจำเพาะ SQL ได้ปลดเปลื้องจากความแม่นยำสูงกว่าเพื่อความแม่นยำที่ต่ำกว่าดังนั้นหากคุณใช้ฐานข้อมูลที่ดีนี้ไม่ควรเป็นปัญหา . ในแอปของคุณเองคุณสามารถตัดทอนได้ทุกเมื่อที่ต้องการ birthday_dateนั่นคือจะบอกว่าผมจะไม่เคยไป


0

ฉันจะใช้คำนำหน้าที่มีความหมายและ _TSMP เป็นคำต่อท้ายเช่น CREATION_TSMP หรือ LAST_UPDATE_TSMP


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
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.