データベースエンジニアを目指せ！
泥縄式データベース勉強法

萩原佳明 （プラスワンデジタル）
2003/5/16

　データベースについて学習し知識を身に付け、その後に経験によって知識の定着化を図る。しかし世の中、そんなにうまく時間が取れることはあまりない（特にエンジニアは）。そんなエンジニアにお薦めできるのが、「泥縄式データベース学習法」。そんなに難しい方法ではなく、エンジニアにありがちな勉強法かもしれない。

誰でも最初はビビリがち

　どうもDB（データベース）と聞くとむやみに大変そうに思え、「なんかヒマだしDBでも覚えようかなぁ」というわけにはいかないような気がする。がしかし、確かに本物のDB屋さんになるのは大変だろうが、そこそこ使えるようになるぐらいなら、なんとかなるんじゃなかろうか。高い金払ってORACLE MASTERの講習なんぞ受けなくても。

　てなわけで、僕がどうやって「なんちゃってDB野郎」になったのかここで書くわけだ、いまから。「どうせ自分にはゼッタイ無理」とか、恋に奥手な中学生女子みたいなこといってるヒマがあったら、取りあえず読んでみてほしい。本物にはなれないかもしれないが、取りあえずやってみないことにはニセモノにすらなれないわけだしね。ちなみに、ここでいうDBはRDBMSのことなんだけど、「ロバート・デニーロ・バイオ・ミステリー・サスペンス」みたいなんでDBと略。

さて、と。

どうして僕なのよ

　それは前世紀が終わりかけたある日のこと。ピロピロと携帯電話が鳴ったので出てみると、僕の心の師匠である某大手レコード会社技術部Bさんの声。

　「サーバ管理やってくんない？ ほら、Linux触ってるとかいってたでしょ？ よろしく」

　「……」

　ムチャな。当時はまだ、「多少PerlでCGI書いたことはあります」といったレベルの僕にとって、その電話はかなりビックリするような依頼だったわけだが、やはり心の師匠のお願いは断りづらく（体の師匠なら断りやすいわけではないだろうが）、元気いっぱいの声で「頑張ります」と返事してみたのだった。が、最初の打ち合わせで驚き。「たぶんDBも必要だと思うんだよね」とかいわれたもんで。

　「えっ、DB？ なんか大変そうなアレですか？ ドラムンベースとかダイダラボッチとかドイツ銀行とかの略じゃないですよね、それ。あははー。ええ、データベースですよね、例のデータがベースしてるやつ。はい、聞いたことあります、食べたことないですけど。いや、もちろん頑張りますよ！」

　打ち合わせの帰りに取りあえず本屋のDBコーナーに行き、適当な本を購入。家で『Oracle入門』（というようなタイトルだったかはすっかり忘れたけれど）を読みつつ、知らない言葉のオンパレードに「なんで広告屋のくせしてストライキなんかしてんだ、ストアドのバカヤロー！」とか逆ギレしそうになっていたところ、妻から「サーバ管理やろうって人が、入門って書いてある本を読んでいてもいいわけ？」なんていわれてもう参った。さて、どうする。

ダメ元でババーンと

　取りあえず先走るのをやめ、落ち着いて考えてみた。そもそも、なんでDBの本なんか読んでるんだっけ？ 以下、心の独白。

　そう、管理を頼まれたのだ、とある会員制のWebサイトの。しかもサーバ管理だけじゃなく、そこで動くプログラムなども全部作ってほしいという話だったのだ。

　師匠いわく「会員情報を管理する必要があるし、DBがあった方がラクだと思う」と。そうだ、「ラク」するために使うんだ。ふん、ラクすんのか、そいつはいいかも。会員制のWebサイトってことは、会員の情報を更新したり追加したり表示したり、最低限それだけをやれりゃいいんだよな、多分。じゃあ難しそうなことは置いておいて、取りあえずそれだけはできるようになってみよう。全然無理そうだったら、「DB使うのはオーバースペックだと思うんですよね」とかいって胡麻化せばいいか……。

　えーとそれから、なんでOracleの本を読んでるんだっけ。特に理由はないのか。Oracleの名前を知っていたのと、本屋に行ったらOracle関連の本がいっぱいあったから雰囲気に流されただけ。しかし、入門書を読んでもどうもよく理解できないし、結局ごまかしてDB使わずに済ませられるかもしれないから、金がかかるソフトウェアは嫌だなぁ。借りているアパートも築30年ぐらいだしさ、僕。

だーっとベース固め

　フリーのDBということで探すと、「PostgreSQL」と「MySQL」がよさそうだ、ということが分かった。が、MySQLは当時GPL（GNU General Public License）ではなく、ちょいと複雑そうなライセンス形態だったのでやめた。DBでいっぱいいっぱいなのに、ライセンスのことにまでアタマを使うだけの余裕はない。というわけで、使うDBはPostgreSQLに決定。シーラカンスが表紙に載っているすてきな本、『PostgreSQL完全攻略ガイド』（石井達夫著／技術評論社刊）を読みながら、とにかく書いてあることを実際に試してみることにした。

　DB自体のインストールは無難に終了。本に書いてあるとおりにするだけだし。実際のDBの操作とか細かい設定とかは分かんないこともたくさんあるけど、取りあえず動いてるみたいだし大丈夫だろう。それに実際に動かしてると、ナゾに包まれていたモロモロが次第に明確になってくる。「なんだよDBって表のことか、早くいえってーの」とか（レベル低すぎでしょうか）。やっぱ取りあえず触ってみるのはよいことだなぁ。とにかく。DBは順序がない表で、PostgreSQLが遺伝的には結構由緒正しいソフトで、DBの操作にはSQLというものを使う、なんてことが分かった（ストアドがスト・アドじゃなくてストアー・ドだと分かったのはもうちょっと後の話）。SQLを学ぶには別にPostgreSQLの本じゃなくても大丈夫ということも判明し不安も少し解消された。PostgreSQLの本ってあまり出てなくてどうしようかと思ってたので心配だったのだ。ということは、お次はとにかくたくさんSQLってヤツを書いてみることだな、きっと。

　というわけで5冊ほど、SQLの本を購入。取りあえず書いてあることを片っぱしから試してみる。GROUP BYとかHAVINGとかサブクエリーとか、つまずきそうなこともあったけど、実際に試しながらだと結構理解できる。少なくとも、そういうことができるんだと分かる程度には。当時のPostgreSQLはOUTER JOINができなかったりして、その関係で覚えなくてもよいこと（というか覚えても仕方がないこと）がいくつかあって、そのあたりも覚える量が少なく済んで助かった。もちろんOralceのみとかSQL Serverのみとか書いてあるSQLは2ナノ秒で無視。

　インデックスってのを使うと速くなるってことも分かり、ダミーデータを山ほど突っ込みつつ、EXPLAINでベンチマーク的なことをしてみるのもなかなか楽しかった。世の中こんなに劇的に速くなることなんかないわよ、奥さん、ってな感じ。カーソルとかはよく分かんないからシカトだ。正規化とか、これでいいのかなぁと思いながらやってる部分もあるのだけど、ま、そのうちなんとかなるだろうと思うことにする。

　取りあえず何ができるか、なんとなく分かったところで再度立ち止まる。会員情報を管理するんだったら、何が必要か。

土台を元にバンバン進む

　会員管理をする必要があるから当然会員のテーブルが必要。それから、会員のフォーラムみたいなのも作る予定なので、そのフォーラムの発言内容を保存するテーブルも必要だ。でも、誰がどの発言したかという情報をフォーラムのテーブルに書いてしまうと、会員テーブルと保存するデータがカブっちゃって無駄だよな。と、そう思った瞬間、正規化ってこういうことかもねーと気付く。考えてみればDBの理論が打ち立てられた当時はリソースが超貴重だったわけで、できるだけ無駄をなくすのがすてきなわけだろう。てことは、「もったいない」を基本スタンスにするのが正解かも。なるほどと思いつつ、カンでやってみる。「もう、パパったらまたトイレの電気つけっぱなし！」とかいいながら。

　それから、Webサイトだから複数の人が書き込んだりするわけで、それの手当を考えなきゃいけないはずだ。ふむ、そうか、DB使えばそういうことは気にしなくていいってことかな。複数のテーブルが絡んだり複数のデータが絡んだりするときだけ、さっき読んだトランザクションとかロックとか、そういうことをすればよさそうだ。ロックにはいろいろ種類があって、といってもハードロックとかグラムロックとかプログレッシブロックとかそういうことではなく、「行ロック」とか「ページロック」とか「テーブルロック」とか、ロックの粒度を考えて使うらしい（リュートって楽器があって、という話を書くのはやめておこう）。そういえばPostgreSQLの本に「ダーティーリード」とか、なんかカッコ良さげなことが書いてあった記憶がある。が、取りあえずスグには理解できそうにないんで、ロックしなきゃマズそうなときはテーブルロックで逃げることにする。使えないほど重くならなきゃ別にそれでいいわけでしょ？

　まあ取りあえずこんなものかと思いながら、あとは実際にどういうページを表示したいのかを考えつつ、そのページに表示したい要素を吐き出すSQLをガンガン書いてみる。WebとDBの連携なんていうと複雑そうだが、しょせんSQLを発行して結果を表示できればいいだけだ。だから表示する必要のあるもろもろをうまく表示できるようにSQLを用意できれば成功、どうも複雑になったり異常に遅くなっちゃうようなら失敗。ま、考えてみれば単純な話ですな。

　スラスラとはいかないが、何度も何度も本をめくりながらズラズラSQLを書きだすと、やはりカンで作ったテーブルはヤバイ部分もある。そんなときは迷わずテーブルを切り直す。DBってDestroy＆Buildの略ですかってくらい。初めてDBに触る人間にとっちゃ、DDLっていうんだっけ、CREATE TABLEなどの構文練習になって好都合だったりするわけだ。

　そんなこんなで、テーブルを作っては壊しをやりながら、普通に変更できちゃいけない管理系の情報はGRANTで権限分けてみたり。といってもその中で一般ユーザーも参照できないといけない項目は抜き出してVIEWにしてみたりする。途中テストでいろいろ触ってたときに「'」が入っている項目を入れようとしたらエラーになり、「これ許しちゃうと勝手にDBに触られちゃう！」ということに気付き、急いでエスケープの仕方を学んだりもする。本に載ってる例を積極的にマネしながら作っていったら一応使えそうなDBが出来上がった。ほう、なんていってるうちにサイトも無事オープン！

　少しドキドキしたけどすでにEXPLAINは趣味の一部と化してたし、基本的に臆病者なのでなるべくカタイ作りにしたし、公開後も重いとかDB荒らされたりとか、そんなことは起こらず意外と平穏な日々を過ごせた。共有メモリがどうとか、ソートバッファのサイズがどうとか、物理ファイルはここに置かなきゃパフォーマンスがどうだとか、そういうことは手が回らなかったけど。取りあえず動いてお客さんに使ってもらえたわけでよかったよかった。

大丈夫、勉強してみよう

　一度動くものを作っちゃうといままでの臆病さも消え、いろいろ試したりするのも気がラクになってくる。そんなころにちょうどMySQLのライセンスが変更になったので、アクセスログの管理に使ってみることにした。さすがに速さが売りのDBだけに、確かに単純な検索ならものすごい速い。ブラボー！「単純な」ってところが、良い意味でも悪い意味でもキモなのかもしれないが、そこはそれ、キャラが立ってるってことはすてきなことだ。PostgreSQLも楽しいけどMySQLもすてき、と思える自分がいたりして、DBはいろいろあるけれど結局のところ本当の基本部分は変わらないんだなと気付く。

　てことはさ、とにかく、何でもいいから触ってみりゃいいわけだ。

　何でもいいから触ってみて、テーブル切ってデータ入れて、SELECTしてみりゃいいだけだ。あとのことはぜーんぶ、その後ですな。

　「どうせ自分にはゼッタイ無理」と思ってたカレと学校の帰り道で偶然バッタリ、「実はオレ、オマエのこと」「え？」「……」「……」「好きだー！」なんてことは絶対に起きないので、まずは触ってみましょう。試してみて本当にダメだったらDBは人にやらせることに専念すれば、きっとその後の人生も平穏に暮らせると思うよ。

筆者紹介■萩原佳明（はぎはらよしあき） 東京大学文科I類中退。アスキーで3年半ほど編集者生活を送った後に独立し、（有）プラスワンデジタルを設立。代表取締役社長ではあるが零細カンパニーのため取り締まる相手なし。現在の主なお仕事はWebサイトの企画・運営やサーバ管理、プログラム作成など。もちろんデータベースの構築も含まれる。

データベースエンジニアを目指せ！ バックナンバー

泥縄式データベース勉強法 データベースは設計と上流から押さえる データベースコンサルタントへの道 データベースの習得に王道はあるか？ データベースの学び方 顧客の変化とともに成長するエンジニアになる 理想のデータベースエンジニアとは？ データベースエンジニアの真髄を見極めよう