Boolean のカラムを生やす前に考えたいこと

その方が単純に情報量が増えるため 最初 boolean にしてたけど後から時刻もほしくなるということはよくある。後から日時型のカラムに変えようと思っても、過去のイベントの日時は失われてしまっていて困る。今は日時が必要でないように感じても日時にしておく方がよい。 またアプリケーション的に使わなくても、データ分析のためにあると嬉しいことは多い。 コード的にも特に扱いにくくなることはない 以下のようにして簡単に boolean と同じ感覚で扱うことができる。 class Post < ApplicationRecord scope :unpublished, -> { where(published_at: nil) } scope :published, -> { where.not(published_at: nil) } def published? !published_at.nil?

[door-s-dev]

んーこの場合datetimeにしたカラムはNOT NULL制約がつけられなそうなのが気になる。それを上回るメリットがあればいいのかな

[Fluss_kawa]

Booleanじゃなくてintにしてビットフィールドで持つべきって話かと思った。

[shingo-sasaki-0529]

アプリケーションレベルで見ると仰る通りだけど、DBレベルで見るとインデックス設計や各種制約をしづらくなるとかあるから適材適所ではありそう。とはいえ大抵のケースでは　Boolean のカラムは不要そうではある

[Soudai]

めちゃめちゃわかりやすくてシンプルで良い記事だった。

[yarumato]

“イベント(done,approve,..)を表す場合、日時型で持った方がいい。boolean completed ではなく、datetime completed_at で持つ。booleanにしてたが後から時刻もほしくなるは頻発。別テーブルにすればissue closeしたuserも記録できる”

[NetPenguin]

*_atなカラムはよく作る。のだけど、enumなカラムの方が作ることが多いかな。インデクスはりたいし。 別テーブルにすることはよく検討する。T字ERでいうところのイベント。 なんにしても安易にbool用カラムは生やさない。

[roshi]

booleanで宣言することで日時の概念を排してる意図を込めたくなるけど基本的には日時型でいいと思う。上位概念に昇華はし過ぎると目的外利用される余地も生まれるのでなかなか難しい。。

[abstruct3431]

そもそもBooleanって「概念」であって「データ」ではないからな。そこを履き違えてる開発者ばかりだけど

[yamadadadada2]

datetimeだとindex効かないケースが出てくるかも？

[fukken]

事前に要件を確定できるシステムか、その後運用するにつれて要件が「育っていく」タイプのシステムかで最適解は異なるだろう。柔軟になることにはデメリットもあるし。

[yojik]

booleanは区分だから区分毎のsubsetにする方が良い(こともある)。例えば会員の有効無効フラグより、会員とsubsetの有効会員・退会会員にわけて必要な区分の会員情報は inner join で絞って取得する(将来区分が増えても対応可能)

[shiroemons]

イミュータブルデータモデルの話かな

[ducktoon]

同じような理由からGoogle関連のAPIにはboolean型が無いとかなんかで見たな