日付を使用して曜日とその数を選択するスクリプトがあります。次のようなもの
_2018-06-04 =becomes=> Monday(04, June)
2018-06-04 =or becomes=> Monday(04) // In no need for Month
_
だから私はDATETIME
データタイプを使用してテーブルに列を作成しています、そして私はこのように値を設定します
_000-06-04 //case1
000-00-04 //case2
_
これはこれを行う適切な方法ですか、それともVARCHAR(18)
データ型を使用して、このように直接書き込むのが良いでしょう
_Monday(04, June) //case1
Monday(04) //case2
_
DATETIME
を使用するには、後でDATE_FORMAT()
を使用する必要があり、VARCHAR(18)
を使用する必要はありません。
_SELECT DATE_FORMAT(date, '%W(%d, %m)') FROM table //case1
SELECT date FROM table //case2
_
使いやすさは気にしませんが、パフォーマンス。
手動のDATE
型で内部的に表現されているように、必要なデータ型に対して最小の3バイトで表されます。 TIMESTAMP
は、エポック(4バイト)から内部的にBIGINT
秒として表されますが、サーバーのTZがUTCでない場合、TIMESTAMP
は常にUTCとの間で強制的に変換されます。これは大きなオーバーヘッドを引き起こす可能性があります。 DATE
は、week()
やmonthname()
などの日付関連の関数と互換性があるため、最適な選択のように見えます。
DATE
は、検索/ソート/結合/グループ/間でVARCHAR(18)
よりもはるかに効率的であるため、VARCHAR()
もオプションではありません。
MySQLが盲目的に文字列(またはblob)として処理できる列も同様です。
MySQLが比較、ソートなどを行う必要のある列は、格納またはフェッチ中に変換を意味する場合でも、MySQLにとって便利な方法で格納する必要があります。これの当然の結果として、表示形式をyyyy-mm-dd
以外にする必要がある場合は、notでDATE_FORMAT()
およびMONTH()
のコストを心配してください。
DATE
には、2つの年月日ではなく、3つのコンポーネントがあります。年がない場合は、MySQLが「日付」と見なしているものが本当にありません。ユーザーが明示的または暗黙的に年を指定しない場合、DATE
は実用的ではありません。年がないDATE
はありません。 「6月4日(月)」は毎世紀約14年で発生します。
(直接関係はありません。)ほとんどすべての状況で、DATE
とTIME
を別々に格納することはお勧めできません。 DATETIME
をその部分に分割するのは簡単です。他の方向に進むのは困難です(たとえば、範囲テストまたはORDER BY
の場合)。
日、曜日、月を別々に保存する必要がありますか?それらを個別に操作またはテストする場合は、おそらく。