達人に学ぶDB設計徹底指南書 第2版

投稿元：

レビューを見る

データベーススペシャリスト試験を受けるので、DB設計でよくおすすめされている本の第2版が発売されたということで読んでみた。
試験の参考としてはもちろんなったのだけど、アンチパターンや非正規化のケーススタディだったりと、実践的な内容に踏み込んだ話もあってためになった。
DB設計を仕事にするなら確かに、読んでおいて損は無いように思う。

RAIDについては、RAIDO10が望ましいとのことで、コストが許すなら確かにシンプルで安全なのだろうなと思った。ただし、クラウド環境ではRAID設定は推奨されてないということで、面白かった。オンプレミスの考えをそのまま持っていくとだめということなのか。

バックアップ方式については、コラムの永久増分バックアップという方式がよさそうだと思った。基本的に、増分バックアップなのだけど、定期的に増分バックアップ分とフルバックアップ分を合成するのだとか。これは確かに、いいなと思う。

コラムでいえば、どうして「リレーション」データベースというのかという話が面白かった。そもそも表形式というものが先にあるのではなく、関係を表すことを意識して作ろうとしたっけっか表形式になったのかなと思った。正規化とか、まさに関係性を強く意識した手法だろうしね。

そういえば、リレーショナルデータベースでは、表に入っているそれぞれの値、Excelでいうセルにたいしての正式な用語はないと書いてあってちょっと驚いた。便宜的にこの本でも、「セル」と書いて説明してあったけど、公式的なものではないのか。

ちょっと気になったのが、P.179に記載の受注テーブルにたいして、
{受注ID}→{受注日}→{商品数}
という推移的関数従属があるという説明に少し違和感があったのだけど、こういうもんなのかな。受注テーブルだけみると、受注日が2024-01-05でも、商品数が4のデータも、3のデータもあるのだけど。
もちろん、もとめたいのは受注日ごとの商品数なわけなのだから何を言いたいのかは分かるのだけど、それなら、
{受注日}→{受注日ごとの商品数}
というふうにならないとおかしくないのかと思った(自分がまだ理解しきってないだけかもしれないけど)。

それと、インデックスをつけてもデータ数が少ないと効果はないというは分かってたけど、その目安について「10万件以下」と書いてあったのが結構衝撃だった。10万件って普通に多いイメージがあるのだけど、効果がないこともあるの？
イメージとしては、100件以下のマスタテーブルだとあまり効果ないというのは分かるのだけど…。

後、標準SQLに配列型というものがあるということを知って驚いた。実際にその型が実装されているDBMSは少ないようだけど、なんで標準SQLに配列型を含めようと思ったのだろう…。

アンチパターンで紹介されていた、単一参照テーブルは普通に今のプロジェクトでも使っちゃってる。なんだかんだいって便利だしね…。まあ、自分が設計するなら確かに積極的には使わないだろうなとは思う。

後、アンチパターンについて、水平分割はともかく、垂直分割の何がいいのかは全く分からなかった。
各テーブルに更新日時カラムがあって、どこかの値が更新されたら自動的に更新日時を更新するという仕組みなら意味ありそうな気はするけど。

ASSERTIONという、制約ロジックは初めて知った。CHECK制約以上に、複雑な制約を行えるということで、うまく使えば安全なデータベースを設計できるようになりそうだと思った。
まだあまりDBMS側でサポートされているわけではないようだけど、今後の動向には注目したい。

なお、トリガーは極力使うべきではないとのこと。言いたいことはわかるけど、更新前の値と比較できるというのはかなり便利な機能だとは思うので、なんとも難しいところ…。

それにしても、やっぱりDB設計がしっかりしてないとプログラミングでいくら挽回しようとしても難しいのだろうなとあらためて思った。以前関わったプロジェクトが、まさにDB設計がうまくできないまま進めてしまったので、その後のプログラミングももちろんうまくいかず。今後は、DB設計をしっかりしていこうと思った。