【データベース】「顧客テーブル」のテーブル設計

顧客テーブルには下記のような情報があります。

顧客テーブルの要素

基本情報

• メールアドレス
• パスワード
• 氏名
• フリガナ
• 生年月日
• 性別

自宅住所

• 郵便番号
• 都道府県
• 市区町村
• 町域、番地等
• 建物名、郵便番号等

勤務先項目

• 会社名
• 部署名

設計パターン

設計パターンはいくつかあります。重要なのは業務要件や実装する機能によってSQLがごちゃごちゃしないかやパフォーマンスに影響がないかを考えてどの設計パターンを選ぶか決めましょう。

1.基本情報、自宅住所、勤務先情報を一つのテーブルで管理するパターン

メリット

テーブルの結合をしないので単純なSQLの発行速度は早いです。

デメリット

自宅住所や勤務先情報をそれぞれ統合した結果の顧客情報を取得したい場合にSQLがごちゃごちゃする形になり検索性能が下がります。

2.customerテーブルには基本情報だけ記録し、自宅住所テーブルと勤務先情報テーブルを分けるパターン

1と3の中間的なテーブルの分け方と言えるでしょう。

3.customerテーブルと住所テーブルに分けるパターン

住所テーブルには自宅住所と勤務先情報のいずれかを記録することになります。

メリット

検索性能が上がる。例えば、「北海道に自宅か勤務先がある顧客を取得したい」と行った場合にSQLがシンプルになり検索性能が上がります。また、ソートやページネーションの実装も楽になります。

なお、Railsで上記のようなパターンを実装する場合は単一テーブル継承(STI)という覚えると便利な実装方法もある。

データ件数的な観点

取引先や顧客によって件数が異なるということは多々あるでしょう。件数が多い顧客のデータを取り出したいために件数の少ない顧客データを取り出すのに時間がかかってしまうというのは少しヤキモキしますよね。

対策

顧客ごとにDBを分ける

同じような内容なのにDBを分けるというのはメンテナンスが大変です。ただSQLインジェクションなどのセキュリティリスクは減ります。

また、負荷が大きい顧客DBを別サーバーに切り出してスケールアウトを行うというような柔軟な設計もできます。

テーブルを分ける

メンテナンス性は上がります。アプリケーションの性質にもよりますがDBを分けるよりは優先度が高い設計になってきそうな気がします。

テーブルも分けない

インデックスなどで頑張ります。一番よく見かける設計かと思いますしファーストチョイスになるでしょう。

テーブルを分けてもパフォーマンスが遅くなる場合もありますしね。