回答編集履歴
2
ソート部分の記述を修正
answer
CHANGED
|
@@ -4,6 +4,6 @@
|
|
|
4
4
|
|
|
5
5
|
* タイムゾーン情報が無い。UTC/GMTなのかJST+09:00なのか分からない。(例えば`"2020-05-23"` だった場合、2020-05-23 00:00:00(JST) か 2020-05-23 23:59:59(JST) とみるかでUTC/GMTでの日付の認識がズレる。
|
|
6
6
|
* 文字列である以上、神経質に考えると日付として不正な文字列があった場合のエラーケースを考える必要がある。
|
|
7
|
-
* `DATETIME`のように内部でシリアル値をもっている（はず）の型と比べて、
|
|
7
|
+
* `DATETIME`のように内部でシリアル値をもっている（はず）の型と比べて、日付でソートをする際にも特にアドバンテージが無い。普通に考えて文字列での辞書順での比較は、`DATETIME`で持っているであろう、よりプリミティブな型での比較より、遅いはず。
|
|
8
8
|
|
|
9
9
|
既に回答いただいているように日付型をもたないDBでは文字列にせざるを得ませんが、UTC/GMT、ローカル時間のどちらかに寄せるか、タイムゾーン情報を入れておく必要があると思います。
|
1
記述を調整
answer
CHANGED
|
@@ -1,8 +1,8 @@
|
|
|
1
1
|
**※すでにBAが付いて質問が閉じてしまいましたが、書いていたので放流させてください：**
|
|
2
2
|
|
|
3
|
-
昔のDBのテーブルやデータを見ていると`"YYYYMMDD`な形式など、`CHAR`や`VARCHAR`など
|
|
3
|
+
昔のDBのテーブルやデータを見ていると`"YYYYMMDD"`な形式など、`CHAR`や`VARCHAR`などの型を使ってもろに文字列にしていた例はありますね。`DATE`や`DATETIME`などのような型があってもそのままにしていたようなケースは多く見かけられました。DBのデータを覗いたときに見た目そのままに認識できるメリットはありますが、
|
|
4
4
|
|
|
5
|
-
* タイムゾーン情報が無い。UTC/GMTなのかJST+09:00なのか分からない。(`2020-05-23
|
|
5
|
+
* タイムゾーン情報が無い。UTC/GMTなのかJST+09:00なのか分からない。(例えば`"2020-05-23"` だった場合、2020-05-23 00:00:00(JST) か 2020-05-23 23:59:59(JST) とみるかでUTC/GMTでの日付の認識がズレる。
|
|
6
6
|
* 文字列である以上、神経質に考えると日付として不正な文字列があった場合のエラーケースを考える必要がある。
|
|
7
7
|
* `DATETIME`のように内部でシリアル値をもっている（はず）の型と比べて、辞書順のソートをする上でも特にアドバンテージが無い。
|
|
8
8
|
|