NASA式、客先でバグが発見されたときのいいわけ「これは成功への過程です！」

　ＮＡＳＡのスペースシャトル延期になりましたけど、
　そのいいわけが、のってました（この記事）


　延期について記者会見したマイケル・グリフィン長官は、第一声で「問題は解決している。これは成功への過程である。決して後退ではない」と強調した。


　ほお、じゃあ、客先で、テスト運用でバグが発見されたときでも、

「バグの箇所はわかっています。これは成功への過程です。決して開発を（もう一度テスト段階に）後戻りさせる必要はない」

　と答えれば、いいわけね！（言い訳ね？）

　言う、勇気のある人は、いってみてください。
　ゆーざーに、ぼこぼこにされても、ウィリアムのいたずらはしりません。


　でも、ＮＡＳＡがこう答えてるから、世の中これで、通っちゃうかも？？



　。。。。。かあ？
　

システムテストでＤＢの処理速度問題を出さない方法を考えてたら、PostgreSQLのしくみ分科会？

　昨日のブログで、まだ、問題があった。
　システムテストをやったときに、ＤＢアクセスで問題があるといっても、おそい！けど、開発方法論上、実際のデータ量でテストするのは、一番最後のほう。どうする（＞＿＜！）って話。

　ウィリアムのいたずらの思いつきをあげると

（１）単体テストで、すでに実際のデータ量でテストしてしまう
→即却下！というか、意味がない。
　というのは、現在の開発において、単体テストの段階では、すべてのシステムの状態は明らかでない。テスト終了後に、大幅な変更が入り、データ量が膨大になった場合、結局、対応できない。
　そして、現在の開発において、結合テストをやってる最中にでも、仕様変更って、はいってくるのよね。。。

（２）スパイラルで開発する
　っていってもねえ。。。実際のところ、スパイラルでやるほど、お金は出ないよね。

（３）ＤＢアクセス部分を共通部品として、先行して開発させ、これの性能テストまでをやってしまう。

　ってことになるのかなあ。。。で、そうすると

（４）ＤＢアクセス部分を、プロトタイプで作成し、ＤＢの性能を明らかにしておく。トランザクション制御など、性能にかかわってくるやばやばなところは、パターンやライブラリにおしこめる。

　って、ところに落ち着くのかなあ。。。

まあ、最近流行の、「アジャイルは人である」的な発想をするなら

（５）ＤＢアクセスに際してのノウハウを身に付けさせる

　ってことになるんだろうけど、だからといって、情報処理試験のデータベーススペシャリストなんかの勉強をさせても、前のブログで書いた程度のことしか、思いつかないわけよ。だめだめでしょ！もっと、専門的な知識をもとめてるわけよね。。。きっと。

　たとえば、PosgreSQLのハッシュインデックスと、アクセス向上とか。。って今書こうと思ったら、こんなサイトをみつけてしまったぞ！

PostgreSQLのしくみ分科会

なんか、おもしろそう。。。

データベースの処理が遅い！どーしよー！というときの対策のまとめ

　きのうのブログで、実際のデータ量で流したら、データベースが遅いというときの話をかきましたが、「じゃあ、どうするの？」というのを書いてなかったので、そのまとめ。

---

　情報処理試験のデータベーススペシャリストに、いちおう受かっているウィリアムのいたずらがお送りする、「データベースの処理が遅いときの改善法」

プログラムをいじらない場合：早くなるかどうかわかんないけど、やってみる？

（１）データ領域を整理する
　VACCUM FULLしてみる

（２）もう一度テーブルをつくって、データをいれなおしてみる
　一度データをいっぱい入れちゃって、インデックスなんかがおかしくなっていたり、壊れていたりして遅くなったときは、意味ある。

（３）インデックスの置き場所を変える
　汎用コンピューターや富士通のしんふぉなんかだと、インデックスの置き場が指定できる。この場合、インデックスのアクセス回数を減らすと（汎用機の場合は、トラック、シリンダ指定ができるので、その指定を使って、できるだけ、シークを減らすようにするらしい。詳しくは知らん）改善される、こともある。

（４）あんまり効果ない場合がおおいけど、メモリをつむっていうので、解決しちゃうこともある

（５）ＤＢのパラメータをいじってみる

・プログラムをいじらない場合：早くなること多し

（６）インデックスをつけて、検索条件を、インデックスで処理できるようにする。

（７）インデックスをハッシュテーブルにしてしまう

（８）シーケンシャルアクセスが、頻繁にあり、更新がないマスタ系の場合、
（オラクルでないとできないかと思うが）ネイティブシーケンスを、シーケンシャル順にすると、早く出来るらしい（聞いたことがあるというだけの話、やったことはないので、詳しくは知らん）

（９）（危険だけど）参照制約とかをはずすと、早くなることも。。。

・プログラムをいじる：いじる範囲が小規模順

（１０）Javaの場合、ガベージコレクション（System.gc())を、ある程度のまとまりごとに（System.gc()を書いて）強制的に行う。
→効果ないことも、多い。

（１１）テーブルアクセスをメモリーアクセスに変える
　更新があったら、テーブルと同時にメモリも書き換え、普段の検索は、メモリから結果を返すようにする。とくに、クライアントサーバーで、クライアント側で返せるようにすると、効果絶大だが、問題は、更新があったとこを、どうやって知るか・・・

（１２）テーブルアクセスを、ファイルアクセスなどに変える
　夜間バッチなど、自分しか、そのテーブルにアクセスしていないことが確実な場合は、なにもデータベースをアクセスする必要はなく、必要なデータをファイルに書き出し、ファイル操作を行い、結果をＤＢに返す（更新する）という形もとれる。

（１３）Ｖｉｅｗを作成する
　ＶＩＥＷはよくない、問題を起こしやすいと、佐藤正美氏は提唱している。
　しかし、複数テーブルのJoinなどでは、Viewさえつくれば、一発！っていうケースも多数ある。そういうときは、Viewに変えるのもいいと思う。
　つまり、Viewは、２階から飛び降りるようなもんだ。
　普段は２階から飛び降りることはしない。
　でも、火の手が上がっていて、飛び降りないと助からないとき、２階なら、無傷ではないかもしれないが、死なない確率も高い。そんなときは、飛び降りるだろう。それと、おんなじようなもんっす。

（１４）アクセス方法を全面的に変える
　毎回全データ読んでいたのを、今回更新されたものしか読まない（履歴は取っておく）など、プログラムを全面的に見直し、かえる。

---

こんな、かんじかな