DBエンジニアのための技術勉強会 に参加してきました

6/6（木）にDBエンジニアのための技術勉強会に参加してきた。

やっぱり外に出て、勉強会に参加することがすごく大事だなと思った。
講演するような人は非常に知識も豊富だし、話もおもしろい。
すごく勉強しているし、本も読んでいるな～。

以下箇条書きでそれぞれの講演のメモとか感想とかをつらつらと書きます。


■SQLアンチパターン

• SQLアンチパターンの本の紹介だった。
• 読んだことあるか持ってる人が会場で3割程度だった。
  これは多いのか少ないのか・・・多いか。
• 他人の失敗を学ぶことで、自分の失敗を回避することを目的にした本

• 各アンチパターンの紹介
• 各アンチパターンには名前がついている
• これが結構重要で、名前がついていることで、
  知識の共有が簡単にできるようになる。
  これはこの講演内でも何回か出てきた、一つのキーワード。
  最初はふーんと思っていたけど、たしかに知識を共有するってコストは高い。
  それを考えると難しいことを一言で理解しあえるのは大きいと感じた。
  これは他のことにも言えるだろうな。
• 全てのアンチパターンが、目的、解決策などを含む定型フォーマットで書かれている、らしい。
• この定型になっているのも、知識を共有する上で大切。
Wiki作るにしてもある程度のフォーマットはあったほうがいいんだろうなと思った。
• 論理設計、物理設計、SQL、アプリケーションに分かれている。
• 各詳細は割愛。

■やはりデータ設計は大切です

• データ設計の設計目標
  • 全然意識していなかったけど、当然設計にも目標がある。
    なんとなくやっているってことは恐ろしいと思った。
  • 業務忠実と　　
  • ユーザ業務、要求事項を忠実に理解し、データ構造に表現すること。
  • 忠実な理解とは、業務の目的、意味などが正確になっていること。
  • データ品質を目的に
  • 業務忠実を検証しやすいこと
• 専門家とは、駄目なもんはダメと言えること　
• あの機能もこの機能も入れたいし、性能は出したいし、品質は良くしたいし、
  スケジュールは短いほうがいいし、お金も安いほうがいいし。
  ちゃんと見切ってあげることが大切だと思う。
• マーチンファウラーは両方とものセミナーに共通して出てきた。
  やっぱり偉人だな。
  本はアナリシスパターンだったが、読んでないのはもぐりかな・・・、もぐりです・・・。
• データ設計の実際（要件定義）　
  • 現行分析を行うことで品質向上。
    8割ぐらいはそのまま使える。
  • フローを作るときは処理はいらない、IPFで作りましょう。

以上。