2017年5月31日 堅牢な実装していくぞぅ！

3行まとめ

• 今日は某大和田メアリー純氏 にNULLの扱いについて教えていただいたのであった٩(๑òωó๑)۶
• エンドユーザーにとってはデータの存在は「あり or なし」でしかないのだが、開発者にとっては「あり or NULL or 空文字」となり考えることが増える。
• データが存在しないというステータスを空文字で表現するのは一般的ではないことを学んだ
  • なぜなら、ないというステータスを作りたいのに 空の状態がある というステータスになってしまい明示的でないため
    • 分かりにくいし気持ち悪い。恐らく将来的にアプリケーション側で複雑化してしまう
  • なぜなら、DB内の処理は「あり or NULL」の方が「あり or 空文字」よりも早いため
    • 例: ダンボールの中に入っているお菓子の数を数える場合、前者はダンボールの数を数えるだけでOKだが、後者は全てのダンボールの箱を開けてお菓子の存在を確認しなくてはいけない
• 前提条件
  • 初めのモデル設計の制約を疎かにするとアプリケーション側で後々何回も条件分岐を書くことになり複雑化する。
  • 逆によく考慮された前提条件がある場合は、アプリケーション側ではシンプルで綺麗な実装が可能となる。(属人化もしなさそう)
  • 極端な例として、アンケートで意見がない人を集計するときに なし という項目にチェックをいれた人と 特になし と答えた人を加算して集計しなくてはいけないという状況は作るべきではない。この状況は あり と なし の2択しか選べないように初めから制約を作っておくべき。
• NULL制約
  • NULL制約を設定した場合、NULLをINSERTすると処理に失敗するようになる。
  • 用途としては絶対に値が入るものに対して制約をかけることが多い。
  • Twitterのように投稿に紐づくuser_id が必ず存在するようなカラムに対して制約をかける。
• 今は開発フェイスなのでまだ良いが、運用フェイズになってしまうとテーブルの構造はコロコロ変えられるものではない。ので今大事！
• 設計は状況に応じて主観をどこにおくかを考えると上手くいきそう。インターフェイスを俯瞰して見れると間違いが少なくなりそう。

speakerdeck.com

わいわい

• omniauth と devise の Gem に興味津々！！ソーシャルサインアップの実装がしたすぎるぞう！！
• 業務でもLINE連携実装の兆しがあり仕事も個人開発もとても楽しい！な！

ランチのときに昔とっても好きだった歌が流れてテンション爆上げ↑↑だったのであった！

www.youtube.com