LoginSignup
32

More than 5 years have passed since last update.

そのCRUD、必要ですか?

Posted at

データベースの基本操作とされるCRUDですが、アプリで実現させる必要は必ずしもないかもしれません。

CRUDって?

改めて説明するまでもないかもしれませんが、CRUDは「Create(新規作成)」「Read(データ取得)」「Update(更新)」「Delete」の4つをまとめて略したものです。

これらの操作はデータを扱う上で欠かせないものではあります。そして、フレームワークのScaffold機能で枠組みを一気に生成すると、たいていCRUD機能がセットでできあがってきます。

すでにある以上そのまま使いがちですが、使う方によっては不要なものも出てきます。

CRU

まずは、D以外のCRUについて考えてみます。

ふつうCは必要ですが、「データを追加するのは管理者だけ」となれば、ユーザー側にCは必要なくなります。

Rはデータの表示ということで、特にAPIサーバとするときには必須となりますが、HTMLまでフレームワークが生成するプロジェクトでの管理画面などでは、「データ表示も編集画面と兼用する」ような構造にすればR専用の画面は不要となります。

何かしらのログのように、「一度記録してしまえばあとは編集すべきでない」ものは、U・Dを殺しておいたほうが便利です。

D

そして、いちばん問題になるのがDです。「個人のメモ書き」や「届いたメール」のように、何とも紐付かないような単票のデータであれば、削除することにも特段の問題は生じません。しかし、多くの実用システムで使われるデータベースはリレーショナルなものですので、追加したデータを削除するには、相応の制約がかかってきます。

  • たとえば、売上管理システムでいったん従業員を登録した場合、(誤登録で即座に削除する場合は別として)売上が上がったあとで従業員を消すとした場合、その売上は帰属未定、あるいは消滅するとなっては好ましくありません。ということで、売上を残す必要がある以上は削除できないことになります。
  • Qiitaでは退会すれば投稿データも消えますが、別なサイトで「退会者のコメント」がそのまま残されていたことがありました。

ということで、リレーションに絡んでくるデータは、単純に削除してしまうわけにも行かないケースがよくあります。「論理削除」なんていう漠然とした概念でくくってしまうこともありますが、「退職者」とか「廃番」のように明確な言葉でできる状態を持つものなら、それになるよう「更新」する、というほうが適切かもしれません。

関連

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
32