Zaman damgası alanlarını en iyi şekilde nasıl adlandırmalıyım?

Bazı zaman damgası alanları (veya diğer tarih / saat stili alanları) oluşturmayı ararken, bunları adlandırmanın en iyi yolu nedir? Sadece record_timestamp koymalı mıyım?

Veri türünü değil, sütunun amacını açıklamanız gerekir. Adın tarih / saat / zaman damgası içerebilir, ancak anlamını da eklemelisiniz. Örneğin

• Oluşturulma tarihi
• Başlangıç ​​tarihi
• StatusTime
• erişilen
• Güncellenmiş

Tarih / Saat / Zaman Damgası vb. Eklenmesi ve eklenmesi, ekleme eklemesinin eksikliğinin başka bir sütunla çakışması durumunda özellikle yararlıdır. Örneğin, bir tablonun hem bir Durum'a hem de bir Durum Zamanına ihtiyacı olabilir.

Nasıl hakkında xyz_atbir için timestampve xyz_onbir için datetarla - ör start_atya start_on?

Normalde alanın içine veri türünü dahil etmekten kaçınırdım - herhangi bir alanın adından tür hakkında bilmeniz gerekenleri çıkartabilirseniz daha iyi olur (bir alanın descriptionolması muhtemel değildir integer) - ancak söyleyebilmek a timestampve a arasındaki fark dategenellikle yararlıdır.

Kullanırım:

• created_at
• updated_at

Profilinize baktım ve SQL Server ile çalıştığınızı ve SQL Server TIMESTAMP veri türünün tarih veya saatle ilgisi olmadığını ve satırları damgalama türünde kullanılacağını söylüyor. Bu, hangi satırların belirli bir zaman diliminde değiştirildiğini belirlemede çok faydalıdır.

TIMESTAMP kullanıyorsanız, bir sütun adı belirtmeniz gerekmez ve SQL Server sizin için bir "TimeStamp" sütunu oluşturur. Ancak "ROWVERSION" veri türünü kullanmanız önerilir ve bu durumda sütun adını belirtmeniz gerekir.

Böyle bir sütun için en iyi ad nedir? Değişir ve VersionStamp, RV vb. Gibi bir şey kullanırdım.

HTH

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

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

Ben gibi sütun adlarını kullanarak bulundu create_time, update_timeve expire_timeo yöntem adlandırma ve özellikleri (RSpec) gelince daha iyi okunabilirlik yol açar.

Tarih damgaları için bir DT öneki kullanmayı tercih ederim. Örneğin: DTOpened, DTClosed, DTLastAccessed. Bu, belirli bir tabloda tüm tarih damgalarının hızlı bir referansı için tüm DTxxxx'i listelememe izin verir.

Texas Instruments için çalışıyorum ve sistemlerinde xxxx_ dttm kullanıyorlar

Ben zaten var olan sözleşmeleri kullanmayı tercih ederim.

Unix ve programlama dilleri, Değiştirme Zamanımtime için geniş kabul görmüş bir sözleşmeye sahiptir .

Yaratılış zamanı için

• BSD ve Windows doğum zamanı kullanıyor
• Windows ayrıca Oluşturma Zamanını da kullanıyor
• xstat kullanır btime
• ext4 kullanır crtime
• JFS ve btrfs kullanıyorlar otime(sorma, "çıkarım" tahmininde bulunma ).

Bu yüzden benim için mtimeve crtimemeta veriler için seçim yapıyorum .

Kullanıcı tarafından sağlanan veriler için alanın temsil ettiği şeyle giderim. Doğum günü ise, sadece diyorum user_birthday.

Kesinlik kadarıyla, bazıları için onları çok fazla hassasiyetle kapatıyor görünmektedir. birthdateBir zaman damgası olarak depolayabilirsiniz (günün sonunda teknik olarak doğurulduktan sonra), ancak SQL spesifikasyonunda yüksek hassasiyetten daha düşük hassasiyete kadar yayın vardır, bu nedenle düzgün bir veritabanı kullanıyorsanız bu bir sorun olmamalıdır . Uygulamanızın kendisinde, gerektiğinde her zaman kısaltabilirsiniz. Söylemek istediğim, asla gitmeyeceğim birthday_date.

Anlamlı bir önek ve _TSMP'yi sonek olarak kullanırdım, örneğin CREATION_TSMP veya LAST_UPDATE_TSMP

Sütun adlarında tutarlılığı korumak için, aşağıdaki sözdizimini kullanmanızı öneririm:

dateCreated
dateUpdated
dateAccessed
dateStarted
date...

@Evan Carroll tarafından önerildiği gibi, modeli kırmak için güçlü bir nedeniniz yoksa, mevcut standartlara uyun.

Eğer bu yeni bir şeyse, size en uygun cevabı takip edebilirsiniz.

* _On ve * _by kullanıyorum çünkü satırın ne zaman ve kimin için tutarlı kalmasına yardımcı oluyor:

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