BBH
-Biz Branding Hub-
投稿日 : 
2019/12/06
更新日 : 
2019/12/06

【DB】避けるべき設計と場合によっては避けた方がいい設計について

DB設計において絶対に避けた方が良いバッドノウハウ。
基本的に避けた方が良いが、場合によっては有効な時もあるグレーノウハウ。
これらについて紹介していきます。

スカラ値の分割

スカラ値とは、一つのカラムに格納されている値のことを指します。
このスカラ値は、なるべく細かく分類した方が、あとあと取り扱いやすくなります。
なぜなら、後から結合するのは簡単ですが、分解するのは難しいためです。

例えば、「氏名:田中太郎」と持つよりも、「姓:田中」、「名:太郎」と言う風に値を保持した方が良いです。
この場合、結合して「田中太郎」に復元するのは簡単です。
しかし、「田中太郎」を「田中」と「太郎」に分割するのは難しいです。
我々人間はなんとなくどこが姓でどこが名か判断がつきますが、それを明確なロジックに表すとなると難しいです。
そのため、プログラム上で分割するのは困難になります。

水平分解はNG

水平分解とは、テーブルを横に切って分割することです。
例えば、受注テーブルを年度ごとに別のテーブルに分けるようなイメージです。

こうすることで、テーブルサイズが小さくなりフルスキャンのコストは下がります。
しかし、メリットとしてはそれくらいで、むしろ以下のようなデメリットの方が大きいです。
①意味的な理由が無い。あくまでDBの物理的な構造の都合に過ぎない。
②拡張性に乏しい。列を追加する場合、全てのテーブルに対処が必要。テーブルが増えるたびにアプリの改修が必要。
③DBMSにはパーティションと言う代替手段がある。

こうした理由から、水平分解を行うことはメリットよりデメリットの方が大きくなります。

垂直分解も基本的にNG

垂直分解とは、テーブルを縦に切って分割することです。
DBでは取得するデータはブロック(レコード)という単位で扱われます。
そのため、カラム数が多いとブロックの容量も大きくなり、取り扱いにコストがかかります。
そのコストを削減するために、1ブロックの容量を小さくしようという発想が生まれます。
これが垂直分解という考え方が現れる背景です。

また、ここでいる垂直分解は論理的な意味を持つ正規化は対象外とします。
あくまで物理的な要請から行われるテーブル分解のことを指します。
例えば、以下のような論理的に意味が無い分解のことを指します。

この分解も
・論理的な意味が無い
・「集約」という手段によって代替可能
という点から基本的には避けるべき設計となります。
(ただし、物理的にどうしても性能がでない場合などは、許容される場合もあります。)

集約

DBのパフォーマンス向上のための方策として集約と呼ばれるものがあります。
集約は目的によって二つに分類することができます。

まず、「列の絞り込み」です。
これは必要な列だけを保持した小さいテーブルを作成することを指します。
テーブルを分割するのではなく、必要な項目だけをコピーしたテーブルを作るようなイメージです。
こうすることでデータのやり取りのコストが削減されます。

次に挙げられるのが、「サマリーテーブル」です。
例えば、数万レコード存在するテーブルのあるカラムの平均値を取りたいと言った場合。
都度全件走査していては、処理のたびに負荷が高くなってしまいます。
そこで、不可の低い夜間帯などに集計結果を計算して、それをテーブルに持たせるのです。
そうすれば、以降は計算を行わなくても、そのテーブルを見れば事足ります。

こうした集約テーブルのことを「データマート」もしくは単に「マート」などと言ったりします。
このように集約を行うことで、DBの負荷を軽減することができます。
ただし、データを複製しているためタイミングによっては、実際のデータと差分が出てくる可能性があります。
そのため、厳密な正確さを要する業務では使用できません。
あくまで、その時の断面だったり、ある程度の近似でさえあれば許容できる、といった場面でのみ使用が可能です。

キーに指定するべき値

キーに指定するカラムは、今後変わることのない値にしましょう。
例えば、名前をキーにしてしまうと、将来変更される可能性があります。
なので、IDなどを振るようにしましょう。

テーブル間で同じデータは型をそろえる

外部キーとなり得る、同じデータはテーブル間で型をそろえましょう。
例えば、従業員テーブルの部署IDと部署マスタの部署IDはデータの型をそろえるといった感じです。
仮にデータ型がそろっていない場合、SQLで型変換を行う必要が出てきます。

ID列の使用

ID列とは、自動で連番を発行してくれるデータ型のことです。
便利な一方、色々な難点も持っています。
例えば、DBMSによって仕様が異なるため、移植性が低いという問題があります。
また、オートナンバリングの機能はその性質上、排他制御がかかり、それによってアクセス集中時などにボトルネックとなる可能性があります。
そのため、メリットとデメリットを天秤にかけて使っていく必要があります。

多段ビュー

ビューは必要なデータだけを切り出せるため、便利ですが、使いすぎると混乱を招く可能性があります。
その例として挙げられるのが多段ビューです。
ビューが多段になることで、テーブル同士の関連がわかりにくくなります。
ある部分の変更があらゆる箇所に影響を及ぼす可能性もあります。
そのため、ビューは原則1段までにするのがシンプルで良いでしょう。

DB

Profile

管理人プロフィール

都内でITエンジニアをやってます。
変遷:中規模SES→独立系SIer→Webサービス内製開発
使用技術はその時々でバラバラですが、C#、AWSが長いです。
どちらかと言うとバックエンドより開発が多かったです。
顧客との折衝や要件定義、マネジメント(10名弱程度)の経験あり。
最近はJava+SpringBootがメイン。

Recommend