2016年11月9日水曜日

RDBアンチパターン - 隠された状態 -

この記事はPHPカンファレンス東京での登壇資料の補足記事です。
当日の話はこちら。

PHPカンファレンス2016でRDBアンチパターンの話してきた #phpcon2016




第二章の強すぎる依存は要約すると


  • RDBを利用する際はリレーショナルモデルが大切
  • 事実を保存をすることが大切
  • レコードに状態を保存すると危険
  • しかし事実を保存する事に拘り過ぎて状態が隠れるともっと危険
  • 状態を保存したい→事実の歴史を保存する


を話をしました。
特に重要な項目について少し補足します。

■事実と状態

リレーショナルモデルの話は@nippondanjiさんの資料が沢山あってとても為になるので読みましょう。


そして理論的な話は奥野さんの本が超オススメです。
一章を乗り越えれれば(そこが1番難しい話なので…)あとはスーッと読めると思います。
超良書なのでぜひ読んで欲しいです。



ここについては珍しい手法とか新しいアーキテクチャの提案じゃなくて「業務系」と呼ばれる界隈では一般的な話です。
金融系だとINSERTとSELECTだけで表現するのは一般的だし業務系出身の私はそれが当たり前だと思ってました。
しかしWebサービスのDB設計を見ると意外とそうではありませんでした。
理由はパフォーマンス上の制限だったりアプリケーション上の制限だったりするのですが1番は「その手法を知らない」というのが1番多かったです。
そのため、今回は敢えてこの話をアンチパターンとして紹介しました。
多分、JJUG CCCやPostgreSQLカンファレンスだと響かない内容だったと思いますがPHPカンファレンスにはマッチしたと思います。
この辺は受託開発してる人は特に気にして欲しいです。
何故なら作ったシステムを作った人たちがずっとメンテナンスする可能性の高いスタートアップと違って、作ったら終わりの場合が多いからです。
なので3年後、5年後に「ある日突然DBの問題が発生する」時にとても苦労するし、例外対応時に全く対応出来なくて苦労するからです。
だからこそ受託開発を行うWebエンジニアの方々にはDB設計を学んでほしいですね。

またDB設計についてはもう何十年も議論されて経験が積み重なって書籍になっています。
オススメの本は沢山あるのですがまずはSQLアンチパターンを呼んでいないならぜひ読みましょう。



ということで「隠された状態」について説明しました。
実はこの問題は完璧に対応するにはとても難しい話です。
パフォーマンスとトレードオフ、仕様変更への対応などで長い目で見た問題が発生しやすいところです。
だからこそ、出来る人はとても貴重で価値が高いといえるので是非是非興味を持って勉強してみてください。
また詳しい人は設計の話、どんどんアウトプットしてほしいですね。
私も沢山の経験に基づいたDB設計の話が聴きたいです!!

ということで補足としては以上です。
他の章の説明はこちらから行けます

PHPカンファレンス2016でRDBアンチパターンの話してきた #phpcon2016


登壇動画