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