DBリファクタリング読書会¶

Database Smells¶

隠れたテーマ: 気づき

ベストじゃ無いプラクティスが前例に 日本的なる前例主義

悲劇を避けるために

ほとんどの問題はテーブル設計に帰着する

リレーショナルモデルを無視した設計

sql and rlational theory art of sql

ストアド、トリガー使ってますか?

実装スピードが速い言語で作った結果、ストアドプロシージャに。。。

• トリガーが連鎖していって酷いことになる

  • テストできない

• トリガーを多用するということはRDB理論に基づいていない設計の兆候

  • トリガーを使いたくなるときは不吉なにおいの兆候

• ストアドの使いどころ

  • 監査ログとかはトリガーでやった方が楽かも
  • 移植性が低いからストアドを使わないという判断
  • 基本的には使わない方がいい。

  • RDBMSのおまけ機能と認識しておくといい
  • 大量に処理するときには良いかも

  • ネットワークの負荷を減らしたいときとか
  • トリガーはソースに見えないので罠になり得る

• 個性的なテーブル

  • 適用期間テーブルにfromしかない
  • 時間依存のデータは過去のテーブルに隔離にしていくといいのでは

  • 時間によって意味が変わるのはよくない

  • 列と行が反対になっている
  • 意味毎にテーブルを分けないといけない
  • eav?

  • entity
  • 何が入るかわからないカラムがあるのはモデリングが足りないんじゃなイカ

  • らくらくERD
    • 複合主キーの組み合わせの限界を超えた
  • DWH.BIは正規化しない * 予備100

• 正規化

  • ないがしろにされがち
  • IPAのデータベーススペシャリストが良い勉強になる
  • 制約がめんどうなので、やりたくないって人が多い
  • 参照整合性が不可の原因になるっていうのは都市伝説?