【前編】DB設計を担当した話

基本設計にあたりDBの設計を行いました！
ここで得た経験をまとめたいと思います。

1. インデックスについて

設計の中でどこにインデックスを貼るのかは記載をしなければなりません。
じゃあどこに貼ろうかなーと考えると分かりません。
まず調べてみましょう。

参考サイト:↓

・SQLの検索条件で頻出する列や、結合条件に指定されている列
・テーブル内の全データの量に対して、取得対象のデータが少ない列
・Bツリーインデックスの場合はカーディナリティが高い列（格納されている値の種類が多い列）、ビットマップインデックスの場合はカーディナリティが低い列

読んでみてどこに貼ればいいのかはなんとなく分かりました。

ただ、、、

決定的な根拠をもってインデックスを貼ることができません。
それは自分の中でインデックスを色々試してみて検索の高速化を体感できていないからです。

まず上司に相談したところインデックスは難しいので一旦置いておくことにしました。
ここでそのままにするのではなく個人的に大量のデータを保持したテーブルを用意して色々試したいと思います。

インデックス勉強しよう。

2. ユーザのタイプ管理について

現在開発中のサービスですがユーザ毎にタイプ（役割のようなもの）を振り分けようと考えています。
※タイプとは一般ユーザ、管理ユーザなど
じゃあどうやって管理をしようかなーーという話です。

最初は種類ごとにテーブルを分けました。
もし4つの種類があったら4つのテーブルを作成しそれぞれ格納しようとする算段です。

利点としてテーブル同士のリレーションが分かりやすくなるというのがあります。
例えばAテーブルに「管理ユーザ」の列があるとします。その際「管理ユーザテーブル」と紐づけることができます。
もしユーザが一つのテーブルにまとまっている場合、「ユーザテーブル」と紐づけることになりテーブルの中身を見ても様々なユーザタイプが混在しているため分かりづらいなーーと考えました。

欠点はユーザの管理が大変、テーブルが多くなることです。
４つ別々のテーブルに同じユーザが登録される可能性があります。DB運用やアプリケーションによって変わってきますが、まあぱっと見煩雑ですよね。。。
テーブルが多くなることも↑と近しいですが、ユーザテーブルが４つ存在するのは煩雑です。

こちらでレビュー頂いたところ、「別に１個にまとめていい」とのことでした。
上記で挙げた利点ですが、結局のところ自分目線で見やすいことが優先されていて整合性がとれない危険性を見落としていました。
勉強になりました。

最終的には１つのテーブルにまとめ、タイプは「role」列に格納し判断するようにしました。
（テーブルまとめると見た目スッキリしたな。。。）

3. データの一意性を保つ

例を出しますと、商品テーブルが存在していて「税抜き価格」「消費税額」「税込み価格」列があるとします。
「税抜き価格」と「消費税額」を加算すると「税込み価格」が計算結果になります。
この場合「税込み価格」列は必要なのか？というお話です。

上記は例ですが、開発中のサービスでは合計を算出するための要素数が複数あり合計を出すために毎回計算すると面倒なので「合計」列を設けそこに格納する？というのが背景です。

結果的には「合計」列は必要ありません。
理由は簡単で普通に計算しろってことですね。計算してわかることをわざわざ列に格納するのはよくないです。
列は無駄に増えるし、もしかすると合計列と計算結果が一致しない可能性も発生します。

これも2.と近しく、自分目線で見やすいことが優先されていて無駄が発生しており、よくないです。

4. 終わりに

個人開発でDB設計を行ったことはあるのですが、自社開発になると考慮すべき点が変わってきますね。
特にインデックス周りについて詳しくないので勉強していきたいです。

5. 予告

11月3日に投稿予定です！
次回は「【後編】DB設計を担当した話」について投稿します！