拙著「44のアンチパターンに学ぶDBシステム」が発売になりました データベースコンサルタントのノウハウちょい見せ

Oracle RDBMSなどのオラクル製品や各種インフラ技術(OS、ストレージ、ネットワーク)といった話題を取り上げます。著者は小田圭二、「門外不出のOracle現場ワザ」、「絵で見てわかるOracleの仕組み」、「絵で見てわかるOS/ストレージ/ネットワーク」などの著作もあります

ホーム > スポンサー広告 > 拙著「44のアンチパターンに学ぶDBシステム」が発売になりましたホーム > 雑談 > 拙著「44のアンチパターンに学ぶDBシステム」が発売になりました

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
[ --/--/-- --:-- ] スポンサー広告 | トラックバック(-) | コメント(-)

拙著「44のアンチパターンに学ぶDBシステム」が発売になりました

正確には、そろそろ店頭に並ぶ頃です。
Amazonだとこちらです。「44のアンチパターンに学ぶDBシステム

DB周りで良く見られる失敗例を紹介しよう、それを他山の石として生かしてもらおう、でも、実際には避けられないことも多いので、苦労している仲間が多いことを再確認して精神衛生上の清涼剤にしてもらおう、というコンセプトの本です

DBマガジンで過去3回の特集+ちょっと書き足したのが本書です。過去3回の特集もそうですし、この書き足しも、本ブログへのコメントを生かしています。そういう意味では皆さんのおかげの本でもあります。過去コメントいただいた方も、そうでない方も読んでみていただければと思います。

データベースやアプリケーション、インフラなどの技術的観点も紹介していますが、売りは、失敗につながる大きな問題として、システムに関わる「人」やプロジェクトにおける人間関係などに焦点を当てている点だと思っています。やっぱり、モノを言うのは「人」ですからね。

いくつかお勧めのアンチパターンを紹介します。
バケツRDBMS(DBを1つの箱としてしか見ていない)、太っちょ(列が多い)、組み合わせ爆発(無意味な直積)、臭い物に蓋をするともっと臭くなる(Viewで隠ぺいを繰り返す)、過ぎたるはなお及ばざるがごとし(インデックスつけすぎ)、トランザクションスコープが不適切、なんでもかんでもリアルタイム集計、不法占拠(不要な表が残っている)、目標なきチューニング、見て見ぬふり(追加開発の際、お茶を濁す)、度を越した楽観、心配屋(安全率に安全率をかける)、自社にあったDBAのあるべき姿が分からない/DB担当の要員アサインが悪い、DBAが育たない、DBチームのリーダー/担当者の権限が弱い

なお、見聞きした事例をそのまま紹介しているアンチパターンはありませんので、誤解しないでください(職業上、それはやっちゃいけないと思うので)。

読んだ方は感想を、Amazonか本ブログのコメントに書いていただけると、次の執筆活動の糧になるので助かります(忙しくても書く気が起きます)。

スポンサーサイト
[ 2009/11/23 23:03 ] 雑談 | TB(0) | CM(2)
どうも初めまして。
「44のアンチパターンに学ぶ DBシステム」を楽しく読ませてもらいました。
感想は私のブログに載せてみました。
良かったら見てやってください。

本を読みながら自分もアンチパターンを紹介したくなりました。
自分は基本的にSE/プログラマなので視点が開発者寄りです。
またOracleよりもSQL Serverをよく使うので、SQL Server特有の話も多いかもしれません。
世間にあふれている話ではないかもしれませんが、読んでやってください。

正規化されていないテーブル
普通ならヘッダーテーブルと明細テーブルにわけるようなところを、ヘッダーテーブル内に「0001; 0002; 0003」のような文字列で明細データを格納していました。
SQL上で結合できず、専用のストアドファンクションでループ処理しながらデータを取得するため、遅い遅い・・・。


ストアド信仰
「何をするにもストアドで!」と信じきっている開発者がいます。
ストアドのメリットは理解できますが、場合によってはアドホックなSQLを使った方が開発効率や保守性が高いこともあります。


主キーを指定しないUPDATE/DELETE文
SQL Serverでは主キーではないカラムをWHERE句に入れてデータ更新をしようとするとテーブルロックが発生するようです。
そのため、同時に更新処理が発生するとブロッキングとデッドロックが多発します・・・。


手続き型から抜け出せない開発者
うまくやればSQL一発で実現できる処理を一時テーブルや変数を多用しながら処理しているプログラムがあります。
パフォーマンスも悪いですし、ロジックも見にくいです。


何でもテーブル
普通なら社員テーブル、部署テーブルみたいに分けるところを一つのマスターテーブルに押し込んで、区分で使い分けているテーブルがあります。
そのテーブルを検索したり、データを確認するたびに「区分が1なら部署で、2なら社員で、3は・・・あれ?なんだったっけ??」と混乱しまくりました。


テーブルやカラムの名前が変
スペルミス、名前と実体がなんか違う、大文字小文字の使い分けが統一されていない、スペースがある、DBの予約語を無理矢理カラム名に使っている、等々。
デバッグしようとしたりすると、思わぬところでSQLエラーが出たりして、泣かされます・・・。


エラーを握りつぶすシステム
これは完全にプログラム側の問題かもしれませんが、データベースでエラーが起きても涼しい顔で動いているDBシステムがあったりします。
気づきにくい小さなエラーだったりすると、長期間放置されたりします・・・。


捨てられないデータ
システムがわざわざバックアップ用のテーブルを作って、どんどこ履歴を溜め込んでいっているシステムがあります。
でもそのバックアップデータを使ったことは一度もありません・・・。


ER図がない、または最初に作ったっきり
そういうシステムを引き継ぐと、全体像がつかめず非常に苦労します。。。
全体像をつかむにはER図だけでなく、できればCRUDマトリックスも用意してほしいですね。
[ 2010/04/29 07:38 ] [ 編集 ]
伊藤さん

はじめまして。
感想ありがとうございます。
これらのアンチパターンも、「あるある」と感じるものばかりですね!
ブログも拝見しました。

いろんな人が経験しているアンチパターンを集めたら
きっと、もっと良いものになるのだろうな
と思いました。

「エラーを握りつぶす」というのは、実際にエラーが起きた時に面倒だった
記憶があります。なんせ、調査できないので。

IT業界まだまだ発展途上・・・ということだと思います。
だからこそ、仕事にもなるし、面白みもあるんですけどね!

ありがとうございました!
[ 2010/05/01 03:48 ] [ 編集 ]
コメントの投稿













管理者にだけ表示を許可する
プロフィール

odakeiji

Author:odakeiji
小田圭二 日本オラクルのテクノロジーソリューションコンサルティング統括本部においてデータベースのコンサルタントをしている。今までのキャリアでは、社内教育部隊で、データベースやOS、ネットワークを教える経験を5年ほど積んだり、コンサル部門で主にDB(インフラ含む)のコンサルを10年程度経験した。また、コンサルタントとして、主に大規模ミッションクリティカルシステムを担当。社内では”火消し”とも呼ばれ、システムトラブルの火消しをいくつも担当していたこともある。
ポリシーは、「OracleもOS上で動くアプリケーションにすぎない。だから、OS、ストレージ、ネットワークを学ぶべき。アーキテクチャから考えろ」。
スキル面の興味は、アーキテクチャ、DBA、インフラ技術、教育、コンサル手法など。
本ブログのポリシーは「週に1回、DBAやインフラ担当者の役に立つ記事を書きたい」です(守れるだけ、守りたい・・・・)
なお、本ブログにおいて示されている見解は、私自身の見解であって、オラクルの見解を必ずしも反映したものではありません。ご了承ください。

私の主な著書の紹介です。もしよかったら、お役立てください。他にもオライリーなどがあります

●「絵で見てわかるOS/ストレージ/ネットワーク データベースはこう使っている」小田圭二 著
私のポリシーである”DBMSもOSの動くアプリケーションに過ぎない”に基づいて、OSとDBMSの関係、ストレージとDBMSの関係、ネットワークとDBMSの関係、を解説した珍しい書籍です。DBを学んでひと段落したら、DB使いもインフラ全体を意識しなければなりませんが、そのような人にお勧めです。企業ユーザー向けのIT本としては、2008年度翔泳社No1だとか(最後は出版社談)。

●「絵で見てわかるOracleの仕組み」 小田圭二 著
教育に携わる者としての私の思い「丸暗記するな。アーキテクチャを知るべき。絵で説明すべき」を具体化した、Oracleの入門書です。Oracle初心者向きですが、Oracleの基礎となる部分の動きを解説しているため、バージョンに依存せずに何年先でも使えます。逆に、本書の内容を理解せずに、ひたすら丸暗記すると応用力が身につきません。この本を読むだけで何かできるようになるわけではありませんが、アーキテクチャを身につけて、本当の技術力を身につける第一歩として欲しいと思っています。

●「44のアンチパターンに学ぶDBシステム」 小田圭二 著
本書は、企業のDBシステムの設計/構築から運用管理、プロジェクト管理までの各フェーズにおけるトラブル(失敗)事例について、アンチパターン(べからず集)とその回避策/防止策として解説するものです。チェックリストとして使っていただいても構いません。分かっていてもアンチパターンは避けられないことも多いものです(政治とか)。そういう方には、同じ仲間は多いのだなと再認識していただくための一服の清涼剤としていただければと思います。

●「門外不出のOracle現場ワザ」 小田圭二 他 著
一番最初に出た本です。結構とがった内容を扱っています。
・パフォーマンス分析の考え方(私の担当)
・性能テストや障害テストの仕方、設計の注意点(主に私が執筆)
・コストベースオプティマイザ(10gベース)のアーキテクチャ
・コネクションプーリング
最新のOracleの内容は含んでいませんが、今でも性能の考え方やオプティマイザの考え方は使えるはずです。オプティマイザをここまで解説している本を私は知りません。

●「続・門外不出のOracle現場ワザ」 小田圭二 他 著
「続」の名前の通り、次に出た本です。ちょっと尖り過ぎたかもしれません^^; でも本当に使う内容を選んだつもりです。一流になりたい・他の人と差をつけたい人にお勧めでしょうか。
・性能の良いSQLの書き方
・文字化けの仕組み
・障害(特に性能やハング)の分析・対応方法(私が執筆)
・障害をリアルタイムに分析・対処する方法(私が執筆)
・オプティマイザの使い方ノウハウ
・アップグレードのノウハウ

●「データベース」小田圭二 他 著
私にしては堅い本です。なんせ、共同執筆者が大御所の國友義久先生です。階層型DBMS、ネットワーク型DBMS、リレーショナル型DBMS、XMLDBMS、OO(オブジェクト指向)DBMS、DBMSの持つ機能、DBMSのセキュリティ、データベースの著作権、監査、モデリング、正規化といった内容を網羅しており、深い記述は無いものの、DB技術全体を抑えるのに向いている一冊です。ある程度技術力がついたエンジニアの方が、DB全体を振り返りたい(勉強したい)というときの最初の1冊としてお勧めです。



上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。