Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
最近、機能の設計をレビューしたり話し合ったりするときに、うん・・・?ってなることがあって、でも駄目な理由をうまく説明できなかったのでちゃんと言語化してみる。ちなみにRailsの話です。 DBには事実だけを記録するようにする 色々開発してきて思ったのは、テーブルに状態を持たせるようにするとあっという間に複雑度が増してしまうということ。 status カラムや hoge_flag みたいなカラムを持つこと自体は全然否定しないけど、本当にそれが最適なのかは慎重に考えた方がよいと思う。 これは例ですけど、会員申し込み => 何か審査 => 会員登録完了 みたいなフローのアプリケーションを作る時に、会員情報のテーブルを1つだけ作りstatus 、approved_at みたいなカラムを突っ込んで、申し込み状態と申込み完了状態を アプリ側で頑張って判定しようとしている例はまれによくある。 こうすると何
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く