Làm thế nào tôi nên đặt tên tốt nhất cho các trường dấu thời gian của mình?

57

Khi tôi đang tìm cách tạo một số trường dấu thời gian (hoặc các trường kiểu ngày / giờ khác), cách tốt nhất để đặt tên cho chúng là gì? Tôi có nên đặt record_timestamp không?

naming-convention

— garik
nguồn

42

Bạn nên mô tả mục đích của cột và không nhất thiết phải là kiểu dữ liệu. Bạn có thể bao gồm ngày / thời gian / dấu thời gian trong tên, nhưng bạn cũng nên bao gồm ý nghĩa. Ví dụ

Ngày thành lập
Ngày bắt đầu
StatusTime
Đã truy cập
Đã cập nhật

Thêm Ngày / Thời gian / Dấu thời gian và như vậy vào cuối là đặc biệt hữu ích khi sự bỏ qua của bổ sung sẽ xung đột với một cột khác. Ví dụ: một bảng có thể cần cả Status và StatusTime.

— Leigh Riffel
nguồn

2

Chỉ cần thêm hai xu của tôi. Tôi đã làm việc với nhiều hệ thống MRP cũ và tìm thấy createdOnUtc và UpdatesOnUtc được sử dụng thường xuyên.

— Geovani Martinez

6

Tôi nghĩ rằng "Đã truy cập" và "Đã cập nhật" có thể không rõ ràng, vì nó cũng có thể ám chỉ boolean (ít nhất là trong thế giới Ruby)

— Artur Beljajev

2

@GeovaniMartinez có thể gây nhầm lẫn, vì có rất nhiều cơ sở dữ liệu SQL, bao gồm PostgreQuery, lưu trữ tại UTC và đọc trong múi giờ của khách hàng.

— Evan Carroll

Và nếu đơn vị thời gian được coi là UTC so với System Local thì chỉ định _UTC trong tên cột. Cảm ơn bạn từ tất cả chúng ta, những người phải duy trì mã sau này.

— Jonathan Fite

Truy cập và cập nhật có thể mơ hồ với việc truy cập hoặc cập nhật của WHO, đây là một điều khá phổ biến để theo dõi

— Joe Phillips

27

Làm thế nào về xyz_atmột timestampvà xyz_oncho một datelĩnh vực - ví dụ start_athoặc start_on?

Thông thường tôi sẽ tránh đưa loại dữ liệu vào tên trường - tốt hơn nhiều nếu bạn có thể suy ra những gì bạn cần biết về loại từ tên của bất kỳ trường nào (một trường được gọi descriptionlà không chắc là một integer) - nhưng có thể nói sự khác biệt giữa a timestampvà a datethường hữu ích.

— Jack Douglas
nguồn

16

Tôi sử dụng:

created_at
cập nhật tại

— David LeBauer
nguồn

2

"Tại" cũng có thể ngụ ý vị trí. Thế còn "khi" thay vì "tại" thì sao?

— Sepster

1

"at" hoặc "as at" được sử dụng thường xuyên trong các tài liệu pháp lý và tài chính để chỉ khi có chuyện xảy ra. english.stackexchange.com/questions/112770/ Hy

— Neil McGuigan 19/12/13

3

Nó vẫn có thể mơ hồ. Điều gì nếu bạn cần biết thời gian và địa điểm được cập nhật? updated_atcó thể là một trong hai. Nhưng tôi nghĩ rằng câu trả lời là, như mọi khi với việc đặt tên, sử dụng tên ngắn gọn nhất để loại bỏ tất cả sự mơ hồ thực tế. Tức là nếu trong một bối cảnh cụ thể có tiềm năng cho một sự nhầm lẫn nào đó, loại bỏ nó, nhưng không sử dụng những cái tên được tiết hơn là cần thiết cho rằng

— nafg

1

làm thế nào về "trên". Mặc dù nó ngụ ý một cuộc hẹn hò nhiều hơn một thời gian, nhưng nó vẫn khá rõ ràng

— Joe Phillips

6

Tôi đã xem hồ sơ của bạn và nó nói rằng bạn làm việc với SQL Server và trong kiểu dữ liệu TIMESTAMP của SQL Server không liên quan gì đến ngày hoặc thời gian và nó được sử dụng để loại phiên bản dập các hàng. Điều này rất hữu ích trong việc xác định hàng nào đã được sửa đổi từ một thời điểm nhất định.

Nếu bạn sử dụng TIMESTAMP thì bạn không phải chỉ định tên cột và SQL Server sẽ tạo cột "TimeStamp" cho bạn. Nhưng nên sử dụng kiểu dữ liệu "ROWVERSION" và trong trường hợp này bạn phải chỉ định tên cột.

Tên tốt nhất cho một cột như thế này là gì? Nó phụ thuộc và tôi sẽ sử dụng một cái gì đó như VersionStamp, RV, v.v ... Điều tôi cho là quan trọng KHÔNG phải là cách bạn đặt tên cho nó mà là bạn sử dụng nó một cách nhất quán trên bảng.

HTH

Tham chiếu: http://msdn.microsoft.com/en-us/l Library / ms182776 (v = sql.90) .aspx

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

— Redar
nguồn

3

Tôi thấy rằng việc sử dụng các tên cột như create_time, update_timevà expire_timedẫn đến khả năng đọc tốt hơn khi nói đến cách đặt tên phương thức và thông số kỹ thuật (RSpec).

— Artur Beljajev
nguồn

1

Tôi thích sử dụng tiền tố của DT cho tem ngày. Ví dụ: DTOpened, DTCloses, DTLastAccessed. Điều này cho phép tôi liệt kê tất cả DTxxxx để tham khảo nhanh tất cả các tem ngày trong một bảng nhất định.

— Michael Riley - AKA Gunny
nguồn

1

Tôi làm việc cho Texas Cụ và trên hệ thống của họ, họ sử dụng xxxx_ dttm

— Barry McQuery
nguồn

1

Tôi thích sử dụng các quy ước đã tồn tại.

Unix và ngôn ngữ lập trình có một quy ước được chấp nhận rộng rãi của mtimecho Thời gian Sửa đổi

Đối với thời gian tạo

BSD và Windows sử dụng giờ sinh
Windows cũng sử dụng Thời gian sáng tạo
xstat sử dụng btime
sử dụng ext4 crtime
JFS và btrfs sử dụng otime(không hỏi, đoán "nguồn gốc").

Vì vậy, đối với tôi, tôi chọn mtimevà crtimecho dữ liệu meta.

Đối với dữ liệu do người dùng cung cấp, tôi đi với những gì trường đại diện. Nếu đó là sinh nhật, tôi chỉ nói user_birthday.

Theo như độ chính xác, đối với một số người dường như treo chúng lên quá nhiều độ chính xác. Bạn có thể lưu trữ birthdatedưới dạng dấu thời gian (sau tất cả những gì bạn được sinh ra về mặt kỹ thuật tại một thời điểm trong ngày), nhưng thông số SQL có độ chính xác cao hơn đến độ chính xác thấp hơn vì vậy nếu bạn sử dụng cơ sở dữ liệu đàng hoàng thì đây không phải là vấn đề . Trong chính ứng dụng của bạn, bạn luôn có thể cắt ngắn khi cần. Đó là để nói, tôi sẽ không bao giờ đi birthday_date.

— Evan Carroll
nguồn

0

Tôi sẽ sử dụng một tiền tố có ý nghĩa và _TSMP làm hậu tố, ví dụ CREATION_TSMP hoặc LAST_UPDATE_TSMP

— Thóc Carroll
nguồn

0

Để duy trì tính nhất quán trên các tên cột, tôi sẽ đề nghị bạn theo cú pháp sau:

dateCreated
dateUpdated
dateAccessed
dateStarted
date...

— Andreas
nguồn

0

Theo đề xuất của @Evan Carroll, hãy tuân thủ các tiêu chuẩn hiện có trừ khi bạn có lý do mạnh mẽ để phá vỡ mô hình.

Nếu đây là một cái gì đó mới thì bạn có thể làm theo bất kỳ câu trả lời nào phù hợp nhất với bạn.

Tôi sử dụng * _on và * _by vì nó giúp tôi giữ nó nhất quán khi nào và ai trong hàng:

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

— Shaunak Sontakke
nguồn