なぜ「inserted_at」でなく「created_at」なのか？

Question

テーブルのカラムによくレコードの挿入日時を設定しますが、そのカラム名でよくみかけるのが「created_at」と「update_at」だと思います。

しかしそれなら「inserted_at」と「update_at」の方が、SQLのコードとも一貫しているのではないでしょうか。

CREATEはCREATE TABLEに使う命令文であり、

そしてINSERTがレコードの挿入に、UPDAEが更新に使う命令文ですから、

れコートの挿入日時を示すならば、「created_at」と「update_at」よりも、「inserted_at」と「update_at」だと思うのですが。

何か事情や、歴史的な経緯があったりするのでしょうか？

「inserted_at」と「update_at」はおかしいですか？

Answer 1

よくあるORM等での話だと思いますので、その前提で話をします。

DBを使うのはオブジェクトの永続化が目的であり、SQLを用いたRDBSでなければならないというわけではありません。そのため、名前をSQLに合わせる必要は無いと考えれます。(実際、MongoDB等のNoSQLを使う場合もありますので)

たぶん、名前の由来はCRUD(create,read, update, delete)からです。RDBへはSQLを用いてinsertという命令になるとはいえ、プログラムから見れば、どこかの保存場所にオブジェクトを作成(create)するのであって、そのタイムスタンプと言うことでしょう。

上の話はDBが表面上は隠されているORMまたはそれに類似したもの(いわば、SQL文を直接書くことがほとんど無いアプリ)の話です。ビジネスロジックをSQLに書くようなDB主体のアプリケーションでもそのような名前が使われている場合は、設計者に聞いてみないとわからないと思います。

Comments

[dameo]

私の周りのNoSQLやORMとかまるで通じない汎用機専門のCOBOLer世代(のうちSQLは分かる人)でも、CRUD図は馴染みが深いようで大抵通じましたよ。彼らも作成日・更新日などの用語を使用し、名前もcreateやupdateにしてくれました。参考までに。

Answer 2

DBMS視点で見るとinsertかもしれませんが、レコード視点で考えるとcreateです。

Answer 3

れコートの挿入日時を示すならば、「created_at」と「update_at」よりも、「inserted_at」と「update_at」だと思うのですが。

基本的に他の回答とほぼ同じような内容になりますが、「INSERT」というのは実装レベルの話（SQL文の命令そのもの）であり、設計レベルではそのエンティティが「作成」された、と捉える方が自然です。

そのデータがSQLの世界だけ完結しているのであればINSERTでも伝わりますが、データを取得して操作するプログラム側の視点で考えれば「挿入」という命名は適切ではありません。どこに挿入したの？という、意味が通じづらい命名になります。

命名を考える時は、実装から離れて、概念レベルでどう名付けるのが適切なのか、という視点を持った方が良いです。