Soru MySQL'de datetime veya timestamp veri tipini kullanmalı mıyım?


Kullanmasını önerir misiniz datetime ya da zaman damgası alan ve neden (MySQL kullanarak)?

Sunucu tarafında PHP ile çalışıyorum.


2304
2018-01-03 16:14


Menşei


bunun bazı ilgili bilgileri var codeproject.com/Tips/1215635/MySQL-DATETIME-vs-TIMESTAMP - Waqleh


Cevaplar:


MySQL'deki zaman damgaları genellikle kayıtlardaki değişiklikleri izlemek için kullanılır ve genellikle kayıt her değiştiğinde güncellenir. Belirli bir değeri depolamak istiyorsanız, datetime alanını kullanmalısınız.

Bir UNIX zaman damgası veya yerel bir MySQL datetime alanı kullanmak arasında karar vermek istediğinizi düşünüyorsanız, yerel biçime gidin. MySQL içinde hesaplamaları bu şekilde yapabilirsiniz ("SELECT DATE_ADD(my_datetime, INTERVAL 1 DAY)") ve değerin formatını UNIX zaman damgasına değiştirmek kolaydır ("SELECT UNIX_TIMESTAMP(my_datetime)") Eğer PHP ile üzerinde çalışmak istiyorsanız kayıt sorguladığınızda.


1559
2018-01-03 16:26



Önemli bir fark şu ki: DATETIME bir takvimi (takvimde bulunan) ve bir zamanı (bir duvar saatinde görülebileceği gibi) gösterirken, TIMESTAMP Zaman içinde iyi tanımlanmış bir noktayı temsil eder. Uygulamanız saat dilimlerini ele alırsa bu çok önemli olabilir. Ne kadar zaman önce '2010-09-01 16:31:00'? İçinde bulunduğunuz saat dilimine göre değişir. Benim için sadece birkaç saniye önceydi, çünkü sizin için gelecekte bir zamanı temsil edebilir. '1970-01-01 00:00:00 UTC'den beri 1283351460 saniye dersem, tam olarak hangi noktada konuştuğumu biliyorsunuz. (Aşağıdaki Nir'nın mükemmel cevabı). [Downside: geçerli aralık]. - MattBianco
Başka bir fark var: "yerel" datetime ile sorgular önbelleğe alınmayacak, ancak zaman damgası ile sorgular - olacaktır. - OZ_
"MySQL'de zaman damgaları genellikle kayıtlardaki değişiklikleri izlemek için kullanılır" Bunun iyi bir cevap olduğunu düşünmeyin. Zaman damgası MattBianco ve Nir saydından çok daha güçlü ve karmaşıktır. Yine de, cevabın ikinci kısmı çok iyi. Blivet'in söylediği doğru ve iyi bir tavsiye. - santiagobasulto
Ayrıca, 1 önemli notu olan DATETIME ve TIMESTAMP, CURRENT_TIMESTAMP, NOW () değerini varsayılan değer olarak sayılabilir, ancak DATE, örneğin, '0000-00-00' varsayılanını kullandığı için kullanamaz. DATE mysql türü ile alana / col'a geçerli tarihi (zaman olmadan) eklemek için bu tabloya kendi tetikleyiciniz. - Arthur Kushman
@DavidHarkness: Dokümantasyonda "Otomatik özellikleri belirtmek için DEFAULT CURRENT_TIMESTAMP ve ON UPDATE CURRENT_TIMESTAMP maddelerini kullanın" yazıyor dev.mysql.com/doc/refman/5.0/en/timestamp-initialization.html - Plap


MySQL 5 ve üstü sürümlerinde, TIMESTAMP değerler, geçerli saat diliminden saklama için UTC'ye dönüştürülür ve geri alma için UTC'den geçerli saat dilimine dönüştürülür. (Bu sadece TIMESTAMP veri türü için oluşur ve değil DATETIME gibi diğer türler için.)

Varsayılan olarak, her bağlantı için geçerli saat dilimi sunucunun zamanıdır. Saat dilimi, açıklandığı gibi bağlantı başına temelinde ayarlanabilir. MySQL Server Zaman Dilimi Desteği.


816
2018-03-02 11:49



Kaynak: dev.mysql.com/doc/refman/5.1/en/datetime.html - Andy0708
Bu OReilly tanıtımı bu konu için çok iyi (PDF üzgünüm) cdn.oreillystatic.com/en/assets/1/event/36/... - gcb
Aynı zamanda olayın doğası hakkında: - Bir video konferans (TIMESTAMP). Tüm katılımcılar, kendi saat dilimine göre ayarlanmış mutlak bir anı referans göstermelidir. - Yerel bir görev süresi (DATETIME), bu görevi New York veya Paris'te çalışmakta olduğum günlerde hiçbir şey yapmamalıyım. O gün sabah 8: 00'de çalışmaya başlayacağım. - yucer
Yani, sunucunun saat dilimini DEĞİŞTİRİR, TIMESTAMP değeri aynı kalacak ya da değişecek? - Andrew
@ UTC olduğundan beri, UTC kalacak. Geriye dönük dönüşüm, ancak "yeni" sunucu saat dilimine dönüşecektir. - nembleton


Her zaman satır meta verisi (oluşturulan veya değiştirilen tarih) dışındaki herhangi bir şey için DATETIME alanlarını kullanırım.

Gibi adı geçen MySQL belgelerinde:

Tarih ve saat bilgilerini içeren değerlere ihtiyacınız olduğunda DATETIME türü kullanılır. MySQL, 'YYYY-AA-GG HH: MM: SS' biçimindeki DATETIME değerlerini alır ve görüntüler. Desteklenen aralık '1000-01-01 00:00:00' ila '9999-12-31 23:59:59' arasındadır.

...

TIMESTAMP veri türü, '1970-01-01 00:00:01' UTC ile '2038-01-09 03:14:07' UTC aralığındadır. MySQL sürümüne ve sunucunun çalıştığı SQL moduna bağlı olarak değişen özelliklere sahiptir.

Genel kullanımda TIMESTAMP'lerde alt sınırı vurma olasılığınız yüksektir - örn. doğum tarihini saklamak.


430
2018-01-04 04:26



sen de vurabilirsin üst Bankacılık veya emlakta olmanız durumunda kolayca sınırlandırın ... 30 yıllık ipotek artık 2038'in ötesine geçiyor - Kip
Tabii ki, 64 bit Unix zaman damgası kullanın. Örneğin, Java’da new Date().getTime() zaten size 64 bitlik bir değer veriyor. - osa
DATETIME için +1: Veri akışımızda, satın alma ve fatura için SQL Server'dan SQL Server'dan, Sanal Mağaza için MySQL Sunucusuna web sayfasında aktarılır, DATETIME, bu veri türü Transact'te de olduğu için Modification Date-Time için daha iyidir -SQL. Ama TIMESTAMP, Transact-SQL'deki diğer bir şey anlamına gelir, MySQL TIMESTAMP, DateTime benzeri olsa da, ROWVERSION gibi İkilidir. Bu nedenle, iki DB'nin uyumluluğu için TIMESTAMP kullanımını önlemekteyiz. - jacouh
Fikrim yok. Sadece MySQL'den çok daha büyük bir sorun ve basit bir düzeltme yok: en.wikipedia.org/wiki/Year_2038_problem MySQL'in zaman damgasının artık 64-bit olduğunu ve her şeyin iyi olacağını düşündüğüne inanamıyorum. Donanımı kontrol etmiyorlar. - scronide
Doğum tarihini biliyorsanız, benim için yaptığım gibi bir doğum tarihi, bir DATETIME olabilir. - Kris Craig


Aşağıdaki örnekler TIMESTAMP tarih türü, değiştirdikten sonra değerleri değiştirdi time-zone to 'america/new_york' nerede DATETIMEdeğişmez.

mysql> show variables like '%time_zone%';
+------------------+---------------------+
| Variable_name    | Value               |
+------------------+---------------------+
| system_time_zone | India Standard Time |
| time_zone        | Asia/Calcutta       |
+------------------+---------------------+

mysql> create table datedemo(
    -> mydatetime datetime,
    -> mytimestamp timestamp
    -> );

mysql> insert into datedemo values ((now()),(now()));

mysql> select * from datedemo;
+---------------------+---------------------+
| mydatetime          | mytimestamp         |
+---------------------+---------------------+
| 2011-08-21 14:11:09 | 2011-08-21 14:11:09 |
+---------------------+---------------------+

mysql> set time_zone="america/new_york";

mysql> select * from datedemo;
+---------------------+---------------------+
| mydatetime          | mytimestamp         |
+---------------------+---------------------+
| 2011-08-21 14:11:09 | 2011-08-21 04:41:09 |
+---------------------+---------------------+

Cevabımı makaleye dönüştürdüm, böylece daha fazla insan bunu faydalı bulabilir, MySQL: Tarih Saat ve Zaman Damgası Veri Türleri.


284
2017-08-21 08:45



Eh, aslında DATETIME Zaman dilimi değişikliği ile etkili zaman değişti, TIMESTAMP değişmedi ama insan temsili yaptı. - flindeberg
Bu komut MySQL 5.6'da çalışmıyor gibi görünüyor set time_zone="america/new_york"; - Manjunath Reddy
İşte set_zone sorununun cevabı İşte. stackoverflow.com/questions/3451847/mysql-timezone-change - Manjunath Reddy
@Flindeberg ile katılıyorum. Zaman damgası, saat dilimini değiştirdikten sonra, tarih saatini değil, doğru zamanı temsil eder - Nitin Bansal


Ana fark, DATETIME sabit iken TIMESTAMP etkilenir. time_zone ayarı.

Dolayısıyla, yalnızca zaman bölgelerinde - veya gelecekte sahip olabileceğiniz - zaman dilimleri arasında senkronize edilmiş kümeler bulunduğunda önemlidir.

Daha basit kelimelerde: Avustralya'da bir veritabanım varsa ve bir veritabanını Amerika'da bir veritabanını senkronize etmek / doldurmak için bir veritabanına bastığımda, TIMESTAMP, olayın gerçek zamanını yeni saat diliminde yansıtacak şekilde güncelleştirilirken, DATETIME yine de zamanı yansıtırdı au saat dilimindeki etkinliğin.

TIMESTAMP'ın kullanılması gereken DATETIME uygulamasının kullanıldığı harika bir örnek, Facebook'ta bulunuyor. Sunucuları, saat dilimlerinde hangi saatlerde yaşandığından emin değiller. Bir keresinde, mesajın gerçekten gönderilmeden önce mesajlara cevap verdiğimi söylediği bir konuşma yapıyordum. (Bu, tabiki, zamanlar senkronize edilmek yerine gönderildiyse, mesajlaşma yazılımındaki kötü zaman dilimi çevirisi nedeniyle de meydana gelmiş olabilir.)


169
2018-01-14 14:26



Bunun iyi bir düşünce şekli olduğunu düşünmüyorum. Tüm tarihleri ​​UTC'de saklamak ve işlemek ve ön uçun belirtilen zaman dilimine göre görüntülediğinden emin olmak isterim. Bu yaklaşım basit ve öngörülebilir. - Kos
@Kos: TIMESTAMP'ın dahili olarak ne yaptığı tam olarak UTC'deki tüm tarihleri ​​saklamaz ve işlemiyor mu? (Sonra yerel saat diliminizi görüntülemek için dönüştürmek?) - carbocation
benim yerel saat dilimi? DB'niz saat dilimimi nasıl biliyor? ;-) Normalde veritabanı ve kullanıcı arayüzü arasında oldukça fazla işlem var. Yerelleştirmeyi yalnızca tüm işlemden sonra yapıyorum. - Kos
@Koz: veri tabanım veritabanlarını bilmez:! Ama zaman damgasını biliyor. Veritabanınız kendi saat dilimi ayarını bilir ve zaman damgasını yorumlarken / temsil ederken uygular. Pekin'de 11 Aralık 2013 tarihinde 1:01 am Çin, Avustralya 11 Aralık 2013 tarihinde 1:01 am olarak zaman aynı anda değil. Google: 'saat dilimleri' ve 'ana meridyen'. - ekerner
Fark, yalnızca kümenin diğer sunucularının saat dilimleriyle ilgili değildir. İlgili ayar, tanımlanmış olan zaman dilimi (varsayılan olarak sunucunun aynısıdır, ancak varsayılanınız herhangi bir MySQL istemcisinden bağlantıda varsayılan olarak istemci tarafındaki sürücüye bağlı olabilir). - dolmen


Bu kararı semantik bir temel üzerinde yapıyorum.

Zamanında bir (daha çok veya daha az) sabit nokta kaydetmem gerektiğinde bir zaman damgası kullanırım. Örneğin, veritabanına bir kayıt eklendiğinde veya bazı kullanıcı eylemleri gerçekleştiğinde.

Tarih / saat keyfi olarak ayarlanıp değiştirilebildiği zaman datetime alanı kullanıyorum. Örneğin, bir kullanıcı daha sonra kaydetme randevularını değiştirebilir.


109
2018-01-03 17:11



zaman damgası-zaman içinde sabit nokta, Koordinatlı Evrensel Zaman datetime - bir bakış açısına göre, bir zaman referansı (ej saat dilimi yerel saat), olabilir .. Koordinasyon Yerel Zaman? - yucer


TIMESTAMP, DATETIME için 4 bayt Vs 8 bayttır.

http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html

Ama scronide gibi 1970 yıl alt sınırı var dedi. Ancak gelecekte olabilecek herhangi bir şey için harika;)


86
2018-01-04 09:00



Gelecek 2038-01-19 03:14:07 UTC'de biter. - MattBianco
Bu aptalca. TIMESTAMP türünün “geleceğe hazır” olacağını düşündüm çünkü nispeten yeni. Farklı zaman dilimlerinde çalıştığınız her defasında datetime'ı UTC'ye ve geri her defasında dönüştürmeyi tercih edemezsiniz. Onlar TIMESTAMP daha büyük yapmış olmalı .. en az 1 bayt daha büyük. 68 * 255 = 17340 daha fazla yıl ekleyecektir ... ancak 32 bit hizalanmayacaktır. - NickSoft
TIMESTAMP'ın neden 2038'de bittiğini biliyor musunuz? Çünkü bir tamsayı ve tamsayılar 2147483647 olan limiti vardır. Bunun sebebi olduğunu düşünüyorum. Türünü varchar olarak değiştirir ve nasıl değiştirileceğini değiştirirse, "geleceğe hazır" olacaktır. - vinsa
@vinsa, o zamana kadar geleceğe hazır olacağını sanmıyorum. Hala Y2K hatasını hatırlıyor musun? 2038 geliyor. - Pacerier
2038'e gelindiğinde, MySQL (eğer hala mevcutsa) TIMESTAMP alanını 4 bayttan daha fazla kullanacak şekilde güncelleyecek ve daha geniş bir aralığa izin verecek - the_nuts


  1. TIMESTAMP, DATETIME için dört bayt vs sekiz bayttır.

  2. Zaman damgaları da veritabanında daha hafiftir ve daha hızlı dizine eklenir.

  3. Tarih ve saat bilgilerini içeren değerlere ihtiyacınız olduğunda DATETIME türü kullanılır. MySQL, AT YYYY-AA-GG SS: DD: SS ’biçiminde DATETIME değerlerini alır ve görüntüler. Desteklenen aralık "1000-01-01 00:00:00" ile "9999-12-31 23:59:59" arasındadır.

TIMESTAMP veri türü, bir dizi '1970-01-01 00:00:01 ′ UTC ile' 2038-01-09 03:14:07 ′ UTC aralığındadır. MySQL sürümüne ve sunucunun çalıştığı SQL moduna bağlı olarak değişen özelliklere sahiptir.

  1. DATETIME, TIMESTAMP, time_zone ayarı tarafından etkilenirken sabittir.

80
2017-12-21 11:12



Açıklığa kavuşmanız gerekir # 4: Kaydedilen zaman damgası, sabit ve göreli olmayan (tamamen agnostik) zaman dilimi için iken, görüntülenen çıktının talep edilen oturumun saat dilimi tarafından etkilendiği sırada. DATETIME, her zaman kaydedildiği saat dilimi ile ilişkilidir ve her zaman bu bağlamda düşünülmelidir, şimdi uygulamaya düşen bir sorumluluk. - Christopher McGowan
Mükemmel cevap. Bu cevabı eklemek için değerleri '2038-01-09 03:14:07' ötesine kaydetmeye çalışırsak, bir hata alırız veya '0000-00-00 00:00:00' olarak depolanır. Zaman kayması değerleri (şifreleme amacıyla) olduğu için bu hatayı veri tabanım için alıyordum. - Earnest_learner