違い - mysql timestamp 比較




MySQLでdatetimeまたはtimestampのデータ型を使用する必要がありますか? (20)

datetimeフィールドまたはdatetimeフィールドを使用することをお勧めしますか?なぜMySQLを使用するのですか?

私はサーバー側でPHPを使って作業しています。


2016 + :あなたのMySQLのタイムゾーンをUTCに設定し、DATETIMEを使用することをお勧めします。

最近のフロントエンドフレームワーク(Angular 1/2、react、Vueなど)は、UTCの日時を現地時間に簡単かつ自動的に変換できます。

さらに:

(サーバーのタイムゾーンを変更する可能性が高い場合を除きます)

AngularJsの例

// back-end: format for angular within the sql query
SELECT DATE_FORMAT(my_datetime, "%Y-%m-%dT%TZ")...

// font-end Output the localised time
{{item.my_datetime | date :'medium' }}

すべてのローカライズされた時刻形式は、 https://docs.angularjs.org/api/ng/filter/date : https://docs.angularjs.org/api/ng/filter/date入手できます。


  1. TIMESTAMPはDATETIMEの4バイトと8バイトです。

  2. タイムスタンプもデータベース上で軽くなり、より高速に索引付けされます。

  3. DATETIME型は、日付と時刻の両方の情報を含む値が必要な場合に使用されます。 MySQLはDATETIMEの値を取得し、 'YYYY-MM-DD HH:MM:SS'形式で表示します。 サポートされる範囲は '1000-01-01 00:00:00'〜 '9999-12-31 23:59:59'です。

TIMESTAMPデータ型の範囲は '1970-01-01 00:00:01' UTCから '2038-01-09 03:14:07' UTCです。 これは、サーバーが実行されているMySQLのバージョンとSQLモードに応じて、さまざまなプロパティを持ちます。

  1. DATETIMEは一定ですが、TIMESTAMPはtime_zone設定によって影響されます。

DATETIMEフィールドもTIMESTAMPフィールド使用しないことをお勧めします。 特定の日を全体として(誕生日のように)表現したい場合は、DATE型を使用しますが、それよりも具体的な場合は、おそらく単位の単位ではなく実際の瞬間を記録することに興味があります。時間(日、週、月、年)。 DATETIMEまたはTIMESTAMPを使用する代わりに、BIGINTを使用して、エポック(Javaを使用している場合はSystem.currentTimeMillis())からのミリ秒数を格納します。 これにはいくつかの利点があります。

  1. あなたはベンダーのロックインを避けます。 ほとんどすべてのデータベースは、比較的類似した方法で整数をサポートしています。 別のデータベースに移動したいとします。 MySQLのDATETIME値とOracleの定義方法との違いについて心配しますか? 異なるバージョンのMySQLでも、TIMESTAMPSの精度はそれぞれ異なります。 ちょうど最近、MySQLはタイムスタンプのミリ秒をサポートしていました。
  2. タイムゾーンの問題はありません。 さまざまなデータタイプのタイムゾーンで何が起こるかについて、ここでいくつかの洞察的なコメントがありました。 しかし、この共通の知識は、あなたの同僚はすべてそれを学ぶために時間がかかりますか? 一方、BigINTをjava.util.Dateに変更するのはかなり難しいです。 BIGINTを使用すると、タイムゾーンの問題が多く発生します。
  3. 範囲や精度についての心配はありません。 将来の日付範囲で短くカットされることについて心配する必要はありません(TIMESTAMPは2038年にのみ移動します)。
  4. サードパーティツールの統合 整数を使用することによって、サードパーティのツール(例えば、EclipseLink)がデータベースとインターフェースするのは簡単です。 MySQLと同じように、すべてのサードパーティツールが「日時」を理解するわけではありません。 これらのカスタムデータ型を使用している場合は、java.sql.TimeStampまたはjava.util.Dateオブジェクトを使用する必要があるかどうかをHibernateで把握してみてください。 ベースのデータ型を使用することで、サードパーティのツールを使用するのは簡単です。

この問題は、お金の価値(つまり$ 1.99)をデータベースに保存する方法と密接に関連しています。 あなたはDecimal、またはデータベースのMoneyタイプ、あるいはすべてのDoubleの中で最悪のものを使うべきですか? これらのオプションの3つは、上記の多くの理由からひどいものです。 ソリューションは、BIGINTを使用して金額をセントに保存し、その値をユーザーに表示するときにセントに変換します。 データベースの仕事はデータを格納することであり、そのデータを収集することではありません。 データベース(特にOracle)で見られるこれらのすばらしさのデータ型は、ほとんど追加されず、ベンダーへのロックインの道を切り開いていきます。


MySQL 5以降では、 TIMESTAMP値は現在のタイムゾーンからストレージのためにUTCに変換され、取得のためにUTCから現在のタイムゾーンに変換されて戻されます。 (これはTIMESTAMPデータ型でのみ発生し、DATETIMEなどの他の型では発生しません )。

既定では、各接続の現在のタイムゾーンはサーバーの時刻です。 タイムゾーンは、 MySQLサーバのタイムゾーンサポートで説明されているように、接続ごとに設定できます。


MySQLのタイムスタンプは、通常、レコードの変更を追跡するために使用され、レコードが変更されるたびに更新されることがよくあります。 特定の値を格納する場合は、datetimeフィールドを使用する必要があります。

UNIXタイムスタンプまたはネイティブMySQL日時フィールドを使用するかどうかを決定することを意味する場合は、ネイティブ形式を使用してください。 そのような方法でMySQL内の計算を行うことができます("SELECT DATE_ADD(my_datetime, INTERVAL 1 DAY)") 、レコードを照会すると値の形式をUNIXのタイムスタンプ("SELECT UNIX_TIMESTAMP(my_datetime)")に変更するのは簡単ですあなたがPHPでそれを操作したい場合。



この記事からの引用:

主な違い:

TIMESTAMPはレコードの変更を追跡するために使用され、レコードが変更されるたびに更新されます。 DATETIMEは、レコードの変更の影響を受けない特定の静的な値を格納するために使用されます。

TIMESTAMPは、異なるTIME ZONE関連設定の影響を受けます。 DATETIMEは定数です。

TIMESTAMPは内部的に現在のタイムゾーンをUTCに変換して格納し、検索中は現在のタイムゾーンに変換し直します。 DATETIMEはこれを行うことはできません。

TIMESTAMPのサポート範囲: '1970-01-01 00:00:01' UTCから '2038-01-19 03:14:07' UTC DATETIMEのサポート範囲: '1000-01-01 00:00:00'から '9999 -12-31 23:59:59 '


timestampフィールドは、 datetimeフィールドの特殊なケースです。 特殊なプロパティを持つtimestamp列を作成できます。 作成および/または更新のいずれかで自身を更新するように設定することができます。

「より大きい」データベース用語では、 timestampは特殊なトリガが2つあります。

正しいものは、あなたがしたいことに完全に依存します。


タイムスタンプデータ型は日付と時刻を格納しますが、UTC形式で、datetimeのように現在のタイムゾーン形式ではありません。 また、データをフェッチすると、タイムスタンプはそれを現在のタイムゾーン時間に再度変換します。

あなたがアメリカにいて、米国のタイムゾーンを持つサーバーからデータを取得しているとします。 次に、米国の時間帯に従って日付と時間を取得します。 タイムスタンプのデータ型の列は、行が更新されると常に自動的に更新されます。 したがって、最後に特定の行がいつ更新されたかを追跡すると便利です。

詳細については、ブログ投稿Timestamp Vs Datetimeを読むことができます。


テーブルに対してUPDATEステートメントを実行するとタイムスタンプが変わることに注意してください。 'Name'(varchar)、Age(int)、および 'Date_Added'(timestamp)という列のテーブルがあり、次のDML文を実行すると

UPDATE table
SET age = 30

'Date_Added'列のすべての値が現在のタイムスタンプに変更されます。



主な違いは、DATETIMEは一定で、TIMESTAMPはtime_zone設定の影響を受けます。

時間帯に渡ってクラスタを同期させた場合、または将来的にクラスタを同期させる場合のみ重要です。

簡単な言葉で言えば、私がオーストラリアにデータベースを持っていて、そのデータベースをダンプしてアメリカのデータベースを同期/埋めると、DATETIMEは新しいタイムゾーンでイベントのリアルタイムを反映するように更新されます。 auタイムゾーンでのイベントの時刻を反映しています

TIMESTAMPを使用すべきであったDATETIMEの素晴らしい例はFacebookにあります。Facebookでは、時間帯に亘って何が起こったのか、彼らのサーバは決して確かではありません。 メッセージを実際に送信する前に、メッセージに返信しているという時間があった会話があった。 (これはもちろん、同期が行われていない時に掲示されていた場合、メッセージングソフトウェアのタイムゾーンの翻訳が悪いために発生した可能性があります。)


本当にアプリケーションに依存します。

Sanghaiの予定のために、ユーザーがニューヨークのサーバーにタイムスタンプを設定することを検討してください。 ユーザーはSanghaiで接続すると、東京のミラーリングされたサーバーから同じ予定のタイムスタンプにアクセスします。 彼は元々のニューヨーク時間から相殺され、東京時間に予定を見るでしょう。

したがって、予定やスケジュールなどのユーザー時間を表す値の場合は、日時が優れています。 これにより、サーバーの設定に関係なく、ユーザーは希望する正確な日時を制御できます。 設定された時間は、サーバーのタイムゾーン、ユーザーのタイムゾーン、または夏時間が計算される方法(変更された場合)の変化によって影響を受けない、設定された時間です。

一方、支払いトランザクション、テーブルの変更またはロギングのようなシステム時間を表す値の場合は、常にタイムスタンプを使用します。 サーバーを別のタイムゾーンに移動したり、異なるタイムゾーンのサーバーを比較したりすることによって、システムは影響を受けません。

タイムスタンプもデータベース上で軽くなり、より高速に索引付けされます。


私の経験から、挿入が一度だけ起こる日付フィールドが必要で、その特定のフィールドで更新やその他のアクションを実行したくない場合は、 日付時刻を使用してください

たとえば、 REGISTRATION DATEフィールドを持つuserテーブルを考えてみましょう。 そのuserテーブルで、特定のユーザーの最後にログインした時刻を知りたい場合は、フィールドが更新されるようにタイムスタンプタイプのフィールドに移動します。

phpMyAdminからテーブルを作成している場合、デフォルトの設定では、行の更新が発生したときにタイムスタンプフィールドが更新されます。 タイムスタンプフィールドが行の更新で更新されていない場合は、次のクエリを使用して、 タイムスタンプフィールドを自動更新させることができます。

ALTER TABLE your_table
      MODIFY COLUMN ts_activity TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP;

私はいつもUNIXタイムスタンプを使用しています。タイムゾーンの調整、日付の追加/減算などを実行するときに、多くの日時情報を扱うときには、健全性を維持するだけです。 タイムスタンプを比較する場合、タイムゾーンの複雑な要因は除外され、サーバ側の処理(アプリケーションコードであろうとデータベースクエリであろうと)で資源を節約することができます。関数。

検討する価値のある別のもの:

アプリケーションを構築している場合、データをどのように使用しなければならないかは決して分かりません。 例えば、サードパーティ製のAPIの項目を使って、データセット内のレコードの束を比較して、時系列に並べるとすれば、あなたの行のUNIXタイムスタンプ。 MySQLのタイムスタンプを使用することに決めたとしても、Unixタイムスタンプを保険として保管してください。


私はこの決定をセマンティックベースで行います。

私は(多かれ少なかれ)固定小数点を時間内に記録する必要があるときにタイムスタンプを使用します。 たとえば、レコードがデータベースに挿入されたときや、何らかのユーザーアクションが発生したときなどです。

日時を任意に設定したり変更したりすることができるときは、日時フィールドを使用します。 たとえば、後で予定を変更して保存することができます。


私は常にDATETIMEフィールドを行メタデータ以外のもの(日付の作成または変更)に使用します。

MySQLのドキュメントでdev.mysql.com/doc/refman/5.1/en/datetime.htmlに:

DATETIME型は、日付と時刻の両方の情報を含む値が必要な場合に使用されます。 MySQLはDATETIMEの値を取得し、 'YYYY-MM-DD HH:MM:SS'形式で表示します。 サポートされる範囲は '1000-01-01 00:00:00'〜 '9999-12-31 23:59:59'です。

...

TIMESTAMPデータ型の範囲は '1970-01-01 00:00:01' UTCから '2038-01-09 03:14:07' UTCです。 これは、サーバーが実行されているMySQLのバージョンとSQLモードに応じて、さまざまなプロパティを持ちます。

TIMESTAMPの一般的な使用の下限に達する可能性が非常に高いです - 誕生日の保存など。


A TIMESTAMPは4バイト、A はDATETIME8バイトが必要です。


私の場合は、UTCをシステム、データベースサーバーなどすべての時間帯として設定します。顧客が別のタイムゾーンを必要とする場合は、アプリで設定します。

タイムスタンプには暗黙的にタイムゾーンが含まれるため、ほとんどの場合、日時フィールドではなくタイムスタンプが優先されます。したがって、アプリケーションが異なるタイムゾーンのユーザーからアクセスされ、ローカルタイムゾーンで日付と時刻を表示するようにしたいので、このフィールドタイプは、データがdatetimeフィールドに保存されている場合よりも簡単に行うことができます。

プラスとして、別のタイムゾーンを持つシステムへのデータベースの移行の場合、私はタイムスタンプの使用をより自信を持って感じるでしょう。その間のsumer時間の変化を伴う2つのモーメントの差を計算し、1時間以下の精度が必要な場合には、考えられる問題はありません。

要約すると、私はタイムスタンプのこの利点を評価します:

  • インターナショナル(マルチタイムゾーン)アプリですぐに使用できる
  • タイムゾーン間の簡単な移行
  • かなり簡単にdiferencesを計算する(ちょうど両方のタイムスタンプを引く)
  • 夏時間の出入りの心配なし

このような理由から、私はUTCとタイムスタンプフィールドを選択します。そして私は頭痛を避ける;)


私はBIGINTUTCを格納している間は単にunsigned を使用します...

PHPの現地時間に調整することができます。

DATETIMEを選択しますFROM_UNIXTIME( integer_timestamp_column )

明らかにその列にインデックスを設定する必要があります。それ以外の場合は、前進はありません。







sqldatatypes