DB設計とSQLは、複雑な構造をともなうDBを扱うシステムの開発において必須スキルとみなされている。データストアがNoSQLであっても、関数従属性やSQLを理解しているかどうかで応用力が違ってくる。それらは建築設計における構造力学のような基礎知識で、これを身につけないままでシステム設計に関われば悲惨な結果を招く。じっさい、そのようなプロジェクトは想像以上に多く、これらのスキルの重大性が広く理解されているとは言い難い。
では一般論として、DB設計とSQLとは学習順序としてどちらが先であるべきなのだろう。筆者はDB設計が先であるべきと断言できる。端的に言えば、SQLの知識なしでもDB設計は学べるが、DB構造をイメージせずにSQLは学べないからだ。まずは適切にDB設計することの難しさや必要性を理解する。そのうえで、端正なDB構造からデータを取り出すためのSQLのスマートな書き方を学んだほうがいい。この順序でないと、アクロバティックなSQLで対処できるからと、的外れなDB構造が容認されるようなことが起こる。
以前の記事でも書いたが、筆者がSQLを学んだのはDB設計を身につけたずっと後のことだった。80年代後半にIBMのオフコンS/38（AS/400の先行機）を使う開発者であった筆者は、そのマシンに搭載されていたRDBの合理的な世界観に魅せられた。ちょうどRDBが業務システム開発に活用され始めた時代で、RDBの利用技術は誰もが手さぐり状態だった。筆者はその頃まだ駆け出しのSEだったが、駆け出しであったからこそ先入観なしでさまざまに試行錯誤できた。先輩技術者の多くは、RDB以前のファイル方式にもとづく設計習慣からなかなか抜け出せなかったように思う。
その頃に使っていたデータ操作手段は、SQLではなくRPGという独自言語で、画面制御とDB操作の両方をこなせる便利なものだった。RPG上で開発された高級言語を駆使することで、「DB設計さえ的確であれば、アプリ開発は簡単」を地でいくような合理化を実現できた。こうなると仕事が楽しくなって、主任設計者として5つのプロジェクトを掛け持ちしていたこともある。
90年頃にマシンがAS/400に換わってから、SQLが使えるようになった。非常に便利なものだったが、データのセットアップや微調整のための補助的手段という位置づけだった。そのため筆者は今でも、複雑な副問い合わせを含むSQLを手引書なしでは書けないという体たらくである。RDBにはSQLが付きものとして理解されることが多いが、筆者にとっては「SQLはRDBを操作するための数ある手段のひとつ」程度の位置づけであり続けている。
2000年代にオープン環境で仕事をするようになって、SQLの達人のような技術者に遭遇するようになった。素晴らしいスキルだと関心したものだが、それにしてもDB構造への批判をともなわないSQLスキルの行使には疑問があった。グダグダなDB構造の上で難解なSQLを書くというのは、あくまでも対症療法でしかない。そもそも端正なDB設計をやれることのほうが優先されるべきで、その上でならアクロバティックなSQLを書く必要はないし、それで物足りない気持ちになる必要もない。
DB設計とSQLを「同時に」学べばいいといった意見があるかもしれないが、それも筆者は賛成できない。私を含めて多くのソフトウエア技術者は、プログラミングへの心理的親和性を職業適性として持っているからだ。厳密に言えばSQLはプログラミング言語ではないのだが、それでもDB設計とSQLを同時期に学べばSQLに関心が傾く恐れがある。じっさい、あるSQLのエキスパートは「自分の役割は効果的なSQLを生み出すことであって、DB設計に興味はない」と語っていた。ゆえに、まずは禁欲的に（つまりプログラミングへの親和性を刺激しない形で）、関数従属性や定義域制約を基礎とするオーソドックスなDB設計を身につけたほうがいい。SQLはその後の学習課題と考えてほしい。
