に参加してきましたので、今日はそのメモを公開したいと思います。*1わたしがこの読書会に参加してみようと思った経緯を先に書いておきますと…
大分以前に購入していたデータベース・リファクタリングだったのですが、読もう読もうと思っていながらも積読本になってしまっていました。そんな中、このDBリファクタリング読書会 第二回 : ATND
これは、この本を読むいい機会だと思ったというのがこの読書会に参加してみようと思った経緯です。
また、先にこの読書会に参加した感想も書いておきますと…
ひと言で言うと、参加してよかったです。
（まあ、参加する前はビビリまくっていて、緊張して死にそうだったんですが…）
参加してよかったなぁと思ったポイントをあげていくと、
- 少人数（16人を上限に絞ってる）で座談会形式でやっていること、
- @akitsukada さんのモデレーターっぷりが素晴らしかった、
- @nippondanji さんの話にいちいち納得だったこと*2、
- 参加者のみなさん、ひとりひとりがみなさんポジティブだったこと、
などなどです。
第三回がいつ開催されるかはわかりませんが、次回も是非参加させていただきたいと思っています。
では、以降がわたしがとってきたメモになります。
Contents.
開会 @akitsukada さん
▶ どういった経緯でやってるのか？
データベースのアンチパターンってどういうのだろうと
データベースリファクタリングという本があるじゃないか
他社のデータベースを知る場はなかなかないじゃないか
そういうことを知る場を提供する
途中でビールがきたら、はじまるかもしれない、ビアバッシュが
＊
Oracle の @yokatsuki さんから挨拶
会場の提供
自己紹介
Oracle University の講師を担当
Oracle を扱う人には限られてしまうので、もっと幅広い人と関わりたい
MySQL、Javaとか…
Oracleのファンを増やしたい
そのための場を提供したりしている
何でこれをOracleでやるの？にはだいたい関わっておられる、と。
Oracleにもともと関わりのない方に関わる場を提供する
＊
OracleとMARVELと提携ということで
AVENGERSのポスターもらったw
ふつーに嬉しい
Ustream 中継
講演 @nippondanji さん：Database Smells データベースの不吉な匂い
付箋に話したいことを書き込んで行く
座談会のテーマにして行く
▶ Database Smells データベースの不吉な匂い
隠れたテーマ
気づき
＊
個人としての見解
Oracle 社とは関係ありません
▶ 自己紹介
ブログ、MySQLサポートエンジニア
▶ 日々の仕事
日々の仕事はサポート
トラブルは日常
難問のラストリゾート、それがサポート！
そのときには炎上してる
そのときには爆発してたり
ときには燃え尽きてたり
▶ サポートの日常
そもそも困ってるからサポートへ
手に負えない
手遅れのパターンが多い
ややこしいパターン
個性的なテーブル
ややこしいクエリ
膨大なスロークエリ
＊
世の中には不吉な匂いで溢れてる
全員が気づいてないことは誰も気づけない
ベストでないことがプラクティスに
代表的なもの
日本的なもの★
→盲目的な前例主義
→変更を許さない官僚主義
＊
たまにはうまい空気をすいましょう
＊
腐海にはいってはならん… by ババ様
▶ システムの移行案件
スキーマは既存システムのものをそのままつかいます
つくりなおす意味あるのかよ
＊
ロジックの実装はすべてPLSQL
それはなぜならアーキテクトがきめたから
処理の大半は整合性チェックだったり…
＊
お見積もりはテーブルひとつにつきホゲ万円
→じゃあ、テーブルを減らそう
死亡確定
テーブル数が減ればいいというものじゃない
▶ ほとんどの問題はテーブル設計に帰着する
ひとことでいうとリレーショナルモデルを無視した設計になっている
リレーショナルモデルをしらずにRDBMSを使うのは、運転の仕方をしらずに車を運転するようなもの
リレーショナルモデル
→集合論理
データベース設計理論
→正規化
▶ アンチパターンのストーリー
Press Enter
オブジェクト志向など実業務では使い物にならない
とおなじように
リレーショナルモデルなんて実践で役に立たないとおもってはならない
▶ RDBMSの落とし穴
リレーショナルモデルに従わなくても強力だったりする
単なるデータのいれものとしてつかってないか
▶ リレーショナルモデルの利点
開発、メンテナンスの効率化
アプリのコード量がへる
データの整合性
Selectがストレートに
パフォーマンスの向上
データベースの変更が容易に
＊
WebPressでの連載の紹介
理論で学ぶSQL再入門
▶ まとめ
世界は不吉な匂いが充満している
感覚が麻痺していないか
内輪の常識を疑う
目を覚まそう
改善した結果どうなるか
くじけずに挑戦する
▶ 危険を回避するために
リレーショナルモデルに従う
データベースの設計には必須の知識
正規化、重複を排除して行く作業
＊
データベースをリファクタリングしよう
▶ 腐海へ踏み込んでしまったあなたへ
ガスマスクを身につけよう
適切な防御でみをまもる
無ければ即死
きちんと設計されていないテーブル→整合性の担保に大きなコストがかかる★
＊
毒ガスの正体をみきわめる
＊
オススメ書籍
座談会のメモ
テクニカル系
ストアド・トリガー
ストアドとアプリの使い分けは？
開発スピード→ノウハウを持っているから
バックグランドで動かす→ユーザには非同期で返しておく（業務系）
＊
トリガー禁止
before/after 中身に何が入ってるかわからない
→デバッグが難しい
→トリガーのネスト
※トリガーを一旦、オフにするという方法。テスト後に戻す。その間、システムは停止。
ー
トリガー使う人は少数派
トリガーを使うということは、リレーショナルモデルにそってない典型
ー
ストアドプロシージャ
リレーショナルモデルにはもともとないもの
できるだけ使わないほうがよい
ケースバイケース、バッチ処理などではよいのではないか
＊
シャーディング・トランザクション
＊
正規化
DWH、BIは正規化しない？
table.yobi1-100 をつくっておく…
＊
ボイスコット正規形をきちんと説明できるか？★
データベーススペシャリストの試験勉強が一番勉強になる
＊
外部キーがあると負荷があがるという都市伝説
チェックしてから更新する
アプリは考慮しない
コードでいうと例外を考慮していない、ようなもの。
＊
区分値マスタ★
一個のテーブルに様々なコードをマスタ管理
ひとつにまとめるのはどうかな、という
ポリモフィック環境を実現するためのもの？
関連を定義しているもの
業務要件からかたまってる？
→でも実際はそんなに更新することはない
RDBMSにおいておかないという考え方もあるが、逆にアプリもしくはDBどちらかしかわからないというふうにしたくもない
ジレンマ
ー
アプリケーション側での制御
ー
パーティションという考え方★
＊
データベースと多言語対応
＊
Suica、消費税が変わると工数が跳ね上がる
なんでか？
買ったときは売掛金だったり。
消費税率の変わるタイミングの考慮をどうするか。
為替と同じロジックで解決できるかも。
＊
スピリチュアル系
経験・体験・文化に関するもの
個性的なテーブルってどんなテーブルのことをいうのか
適用期間というなんだけど、from しかない
時間経過でステータスが変わる
→リレーショナルモデル的に難しい
→論理集合じゃなくなる
＊
別のところで生成されたデータベースをそのままのフォーマットでDBにつっこむ
値によって意味を変えるカラム、よろしくない
入れ物として使ったRDBのさいたるもの→EAV
ー
複合主キーの数が大量（16-32）で構成
おまけ
- facebook group: http://www.facebook.com/groups/208894612529828
- wiki: http://devtesting.jp/dbrr/?FrontPage
※ここにはあとですこし追記するつもりでいます。
