データベースの基本操作とされるCRUDですが、アプリで実現させる必要は必ずしもないかもしれません。
CRUDって？
改めて説明するまでもないかもしれませんが、CRUDは「Create（新規作成）」「Read（データ取得）」「Update（更新）」「Delete」の4つをまとめて略したものです。
これらの操作はデータを扱う上で欠かせないものではあります。そして、フレームワークのScaffold機能で枠組みを一気に生成すると、たいていCRUD機能がセットでできあがってきます。
すでにある以上そのまま使いがちですが、使う方によっては不要なものも出てきます。
CRU
まずは、D以外のCRUについて考えてみます。
ふつうCは必要ですが、「データを追加するのは管理者だけ」となれば、ユーザー側にCは必要なくなります。
Rはデータの表示ということで、特にAPIサーバとするときには必須となりますが、HTMLまでフレームワークが生成するプロジェクトでの管理画面などでは、「データ表示も編集画面と兼用する」ような構造にすればR専用の画面は不要となります。
何かしらのログのように、「一度記録してしまえばあとは編集すべきでない」ものは、U・Dを殺しておいたほうが便利です。
D
そして、いちばん問題になるのがDです。「個人のメモ書き」や「届いたメール」のように、何とも紐付かないような単票のデータであれば、削除することにも特段の問題は生じません。しかし、多くの実用システムで使われるデータベースはリレーショナルなものですので、追加したデータを削除するには、相応の制約がかかってきます。
- たとえば、売上管理システムでいったん従業員を登録した場合、（誤登録で即座に削除する場合は別として）売上が上がったあとで従業員を消すとした場合、その売上は帰属未定、あるいは消滅するとなっては好ましくありません。ということで、売上を残す必要がある以上は削除できないことになります。
- Qiitaでは退会すれば投稿データも消えますが、別なサイトで「退会者のコメント」がそのまま残されていたことがありました。
ということで、リレーションに絡んでくるデータは、単純に削除してしまうわけにも行かないケースがよくあります。「論理削除」なんていう漠然とした概念でくくってしまうこともありますが、「退職者」とか「廃番」のように明確な言葉でできる状態を持つものなら、それになるよう「更新」する、というほうが適切かもしれません。