のだめ開発を考える中で、SEとPGと…DBAと書こうとして躊躇してしまったのだが、DBAについて書いておこう。
数日前に、プログラマのためのSQL 第4版 すべてを知り尽くしたいあなたに を買って読んでいるのだが、20年前位だったか年配のコンサルタントの人に「データベースを扱う人ってのは、プログラマなんでしょうか？それともシステムエンジニアなんでしょうか？それとも SIer？」というのを尋ねたことがある。そのときに、DBA（Database Administrator）という分野の人をいることを知った。当時、会社で Oracle の設定をしていたり、SQL Server のチューニングをしていたので、テーブル設計をするとか、テーブルに効率よくアクセスするとか、を「誰が責任をもって担当するのか？」を知りたかった頃である。実務的には「プロジェクト内でデータベースに詳しい人」が担当する訳なんだけど、大規模プロジェクトになると大手 SIer（元請けという意味で）のSEが設定していたりする。それが SE なのか DBA なのかは、今もってわからないけど、じゃあ、テーブル設計は誰が責任を持つのか？というのは「DBA」という答えだったのだが、その「DBAの人は何処にいるのか？」という答えは得られなかった。つーか、はぐらかされてしまったんだよね。
そう、今思うと、そう意味での DBA なんて当時、何処にもいなかったのだよ。
「そういう意味での」ってのは、
- Oracle や SQL Server などのデータベース設定ができる
- Oracle や SQL Server などのデータベースのチューニングができる。
- データのテーブル設計（論理設計、正規化）が適切にできる。
- テーブル等の物理配置が適切にできる。
- テーブルにアクセスするための、効率のよい SQL が書ける。
- テーブルにアクセスするための、ストアドプロシージャなどが適切に書ける。
ってことになる。このストアドプロシージャを使うのが、プログラマだったりするからだ。
当時、大手 SIer の SE な人がやっていたのは、サーバーのセッティングとデータベース等のインストールで（内部的には DBA という分掌だったかもしれないが）、1と2の分野を担っていた。だから、3以降は、誰がやるのか決まっていなかったんだよね。元請け/下請けの関係の場合は、設計書として「テーブル設計」があるから元請けが作成することが多いのだが、果たして、5や6のように「効率よく」アクセスできるかどうかは抜け落ちてしまって、場合によっては、正規化ができていないテーブル構造がでてきたりする。だが、下請けにとって、その「まずい」テーブル設計を修正する手段を持たされていないので、その「まずい」設計のままモノ（コード）を作らざるを得ないパターンに陥る。
近年になって Web システムがこなれてきたので、データベースの設定や設計に関しても小規模に行うようになったから（ Oracle のインストールは、昔はひと苦労だったのだ）、このあたりの分け方が随分マシになったのだが、それでもデータベースのテーブル設計が「？」なものは多い。まあ、そりゃ、データベースのプロじゃないから仕方がないよね、と思っていたものの、じゃあ「本物のDBA」は何処にいるんだ？って話になる。そう、俺＝プログラマの視点から見たときに、先の1～6までを担ってくれる DBA はいるのだろうか？ いや、そもそも、1～6までは DBA の担当なのだろうか？という疑問がでてくる。
この本の邦題は「プロうグラマのための～」になっているが、原題は「Joe Celkos SQL for Smarties, Fourth Edition: Advanced SQL Programming」になっている。for Smarties というのは「賢いやつ」とか「知ったかぶりの」という意味もあるので（ “for Smarties” で検索すると定番のタイトルらしいので、皮肉なのか？）まあ、プログラマに限らない。
DBA はストアドプロシージャを書くのか？
データベースに効率的にアクセスするならば、ストアドプロシージャを書くのは「DBA」であるべきだ。なぜならば、プログラマよりも DBA のほうがテーブル構造を熟知しているし、下手なプログラマやなんちゃってSEがあれこれやるよりも、きちんとテーブル構造を知っている人がコードを書いたほうがいい。これは、昔からよく見ている。だが、その DBA が何処にいるのかという判然としない。理想的なのは、開発プロジェクト内に DBA が1名以上いて、その人が先に書いた1～6までの作業を請け負ってしまうのが望ましい。
しかし、ストアドプロシージャ自体にビジネスロジックを書いたり、テーブル自体が200個位あるような規模のプロジェクトになると、1名では足りなくなって複数名必要になる。しかも、業務ロジック（Web APIも含むだろう）をプログラム側から呼び出すようになると、きちんと設計すると、プログラマの半分ぐらいは DBA が必要となる規模になってしまう。これは何か変だ。DBA が何処にいるかわからないのに、そんな数の DBA を集めるのは不可能だから、DBA の仕事を減らすために（現実的な規模におさめるために）、1と2ぐらいの仕事だけを DBA に割り当てる。そうなると、非DBAな人（SEやPG）がテーブル設計をして、テーブルアクセスも非DBAがやるという、素人臭いデータアクセスの設計／実装になってしまう。これも変だ。
じゃあ、DBA が足りないのだから、もっと作ればいいじゃないかと思うだろうが、そうそうデータベースに精通している人がいるわけでもなく、まあ、そんなことをやるよりも、LINQ でアクセスするとか、コードファーストで作ってしまおう、という発想になってしまうのも無理ないことだ。実際、そういうパターンになる場合も多いだろうし、小規模な WEB システムであればそれで十分な場合も多い。しかし、それが「理想的」なのかといいえばそうではない。では、DBA の理想は何処にあるのだろうか？
DBA の必要条件
人数が少ない（居るのか居ないのかわからないけど）理想的な DBA が少数であると仮定して、その制約条件を考えてみよう。例えば、20名のプロジェクトで1名の DBA だけを想定する。均等に仕事を割り振ると、プロジェクトの5%の仕事が DBA に割り振られることになる。そのほかの仕事は、SE, PG, PM, PL などに割り振られる。そうすると、
DBA が最低限しなければいけない仕事に絞ると、
- データベースのチューニングが可能である。
- 正しいデータベースアクセスの解答を導き出せる。
を持っていれば十分な気がする。近年 Oracle や MySQL, SQL Server などのデータベースの設定自体はそれほど難しくはない。場合によっては、標準的な設定でも十分可動できたりする。
しかし、利用するメモリや、テンポラリディスクの物理配置、ログの切り捨てやバックアップ計画などの標準的なものから、環境にあわせた「チューニング」は必要だ。チューニング≒高速化は DBA にとっては必須条件ではないだろうが、システムの予防策を組む場合には必須となる知識だろう。逆に言えば、標準を超える閾値が何処なのかを知っておくだけでも十分だ。データベースアクセスの頻度など閾値を超えなければ、標準的な初期設定だけで十分だったりするし、最近はそれぞれのパターンが用意されている。
2つめの「正しいデータベースアクセス」は、「テーブル構造を作成する」よりも優先するのではないか、と思っている。業務フローなどからテーブル構造を作っていくのは結構大変な作業になる。生産現場などで使う200以上のテーブルを、5%の作業量しか持たない DBA に全て積んでしまうのは作業量的に無理がある。となれば、おおまかなテーブル構造や、アクセスの仕方は SE, PG が作ってしまい、それが「正しいデータベースアクセス」になっているかどうかを、チェックする係になってはどうだろうか？ゲートキーパー的な役割だ。
プログラムからのアクセスは、「ストアドプロシージャ」、「SQL文」、「LINQ」などの様々な手段があるから、それを統一するか場合によって選択するかはプロジェクトによって異なる。SE が作るテーブル構造も、アクセスしやすいようになっているか、最適なのかは分からない。ある程度の正規化ができていればそれで充分であろう。最適を求めるのではなく、工学的な準最適化を求めるのであれば、それほど細かく正規化する必要もない。また、データにあわせて非正規化する必要もない。そんな中で、統括的な意味あいで DBA という存在が、ひととおりの整合性をチェックし、経験上（そう豊富な実務経験は必要だろう）落とし穴になりそうな部分を潰しておき、後々に陥らないように予防しておくのだ。
これだと、少数の DBA でもなんとかできるかもしれない。そう先の2の要件とプラスアルファがあるだけだ。
で、何処に DBA はいるのか？
つらつらと「プログラマのための～」を読んでいて、DBA について考えなおしたのだが、そうなると著者は、まあ DBA としても、他に誰が DBA として適当なのだろう？という疑問がでてきる。いわゆる、資格としての DBA じゃなくて、実務的なプロの DBA だ。中国地方にひとりいるような気もするし、関東では出会ったことがないような気もするし、もっと閾値を下げてしまえば、プログラマを20名集めて、ひとり DB に詳しい人がいれば、その人をプロジェクト内の DBA とするのが現実的な解じゃないかなと思ったり。
