ActiveRecordのmigrationで付くt.timestampsのcreated_at/updated_atはメタ用途に限定し、whereやsort条件に使わず別カラムで保持すべきだと主張。
日付値がロジックを持つ ことは容易ではない。日付値を使うロジックを実装するのは容易だが。おそらく言語上の誤り
レコードがimmutableであればイベント時刻=created_atと見なしても実運用上そこまで問題は無いと思う。そういう意味では取り扱いが危ないのはupdated_atの方。
積極的には用いないけど、カラム追加がめんどくさい時に見たりしている
例えば「その日の売り上げ」データを created_at で集計すると日付をまたいで営業したときにバグるし、システム障害とかでデータを入れなおすときに特定の日付で入れる必要がある。それよりは別に日付カラムを作るべき。
まったく同意なのだけど、最近のインターネット界隈、15〜10年くらい前に議論された事が再燃している印象がある。サロゲートキーの話とか。そのうち削除フラグの話も再燃しそうな気がする。
データの一括入れ直しをします！みたいなのがあると狂うよね
危険だから使わないのもいいよね！！！！！！！
データ移行とかメンテとかで差し込まれたレコードが破滅するのでやめとこう。
削除フラグなんかもそうだけど、データベースにおける意味と業務上の意味は分けないといけないね。 ログテーブルならいいと思うけどね。
カラムとして露出するんじゃなくて、ファイルシステムのようにレコードのメタデータとして自動的に付与されるといいんだけどなーと思う時はある。
created_atはレコード作成日時であり、業務イベント発生日時ではない。集計条件などに流用せず、shipped_atのような専用カラムを別途用意すべき、という主張。
月ずれ、期ずれがある業務でやられる
まずテーブルをリソースとイベントで分ける。リソースの作成日時は、リソースが作られたイベントのテーブルの方に入れる …ってのが理想論じゃなかかな。実際にやるかどうかは別として
メンテ的に意図的に過去データ挿入する場合もあるだろうし本当にYES。業務用の日時は別途持つ。
テーブルの created at にサービスのドメインロジックを持たせない - めもるが
ActiveRecordのmigrationで付くt.timestampsのcreated_at/updated_atはメタ用途に限定し、whereやsort条件に使わず別カラムで保持すべきだと主張。
日付値がロジックを持つ ことは容易ではない。日付値を使うロジックを実装するのは容易だが。おそらく言語上の誤り
レコードがimmutableであればイベント時刻=created_atと見なしても実運用上そこまで問題は無いと思う。そういう意味では取り扱いが危ないのはupdated_atの方。
積極的には用いないけど、カラム追加がめんどくさい時に見たりしている
例えば「その日の売り上げ」データを created_at で集計すると日付をまたいで営業したときにバグるし、システム障害とかでデータを入れなおすときに特定の日付で入れる必要がある。それよりは別に日付カラムを作るべき。
まったく同意なのだけど、最近のインターネット界隈、15〜10年くらい前に議論された事が再燃している印象がある。サロゲートキーの話とか。そのうち削除フラグの話も再燃しそうな気がする。
データの一括入れ直しをします！みたいなのがあると狂うよね
危険だから使わないのもいいよね！！！！！！！
データ移行とかメンテとかで差し込まれたレコードが破滅するのでやめとこう。
削除フラグなんかもそうだけど、データベースにおける意味と業務上の意味は分けないといけないね。 ログテーブルならいいと思うけどね。
カラムとして露出するんじゃなくて、ファイルシステムのようにレコードのメタデータとして自動的に付与されるといいんだけどなーと思う時はある。
created_atはレコード作成日時であり、業務イベント発生日時ではない。集計条件などに流用せず、shipped_atのような専用カラムを別途用意すべき、という主張。
月ずれ、期ずれがある業務でやられる
まずテーブルをリソースとイベントで分ける。リソースの作成日時は、リソースが作られたイベントのテーブルの方に入れる …ってのが理想論じゃなかかな。実際にやるかどうかは別として
メンテ的に意図的に過去データ挿入する場合もあるだろうし本当にYES。業務用の日時は別途持つ。