ECサイトのモデリング（住所編）

システムエンジニアの村上です。

入社してもう半年が過ぎました。
ここ半年間のほとんどは、社内のECサイトの開発を行ってきました。

弊社のECサイトは、railsのECサイト構築フレームワークspreeの後衛「solidus」を使用しています。
solidusは、なかなか大きいオープンソースですが、実際にECサイトを運営する上で必要な機能が十分に組み込まれていて、
ドキュメントも豊富なので、railsエンジニアなら一度目を通しておいて損はないかと。

そして、データモデリングに関しても参考になるところが多かったので、
solidusをベースに、ECサイトのモデリングについて解説していきます。

今回は住所周りです。

住所の仕様

• 会員情報を保持するユーザーテーブル
• 商品購入の際に必要となるデータを保持する注文テーブル

が存在するとして、
住所情報の用途から考えていきます。

ECサイトなので、購入した商品を配送するための配送先住所が必要になります。
この配送先住所は注文データ単位で登録していきます。

また、注文するたび、住所を一から入力するのは親切ではないので、事前に登録した住所情報を使えるようにすると、
ユーザー自体にも住所情報を持たせる必要も出てきます。

モデリング

単純にユーザーテーブルと注文テーブルそれぞれに住所情報を持たせると、
都道府県、市町村、番地、建物名、郵便番号などのカラムがそれぞれのテーブルに作られます。

この場合、注文データの配送先住所をユーザーの登録済み住所を元に登録する際、カラム一つ一つに格納していかねばならないですし、
そもそも正規化されていないので、共通の住所情報を新たに住所テーブルとして抜き出します。

すると以下のような構造になります。

上記の構造だと、
注文データの配送先住所に、ユーザーの登録済みの住所を利用したいときは、
ユーザーと紐付いている住所レコードを、該当の注文レコードにも紐付ければ良いだけです。

また、注文データに配送先住所とは別に請求先住所を加える場合も、外部キーを１つ追加するだけで済みます。

ただし、ちょっとした工夫が必要

注文データとユーザーが住所テーブルを共有する場合、それぞれ同じ住所レコードを参照している可能性があります。

この状態で、ユーザーが住所情報を変更してしまった場合は、住所データの住所情報も変更されてしまいます。
実際にECサイトを運営していて、注文時に登録した住所が勝手に変更されてしまったら、大変ですよね。

ですので、

• ユーザーが住所情報を更新した場合は、新しく住所レコードを作成して、新しい住所レコードとユーザーを紐付かせる
• 一度作成された住所レコードは更新不可(ReadOnly)にする
• 同じ内容の住所レコードが作成されないように、住所更新or新規作成の際は既存のレコードを確認し、すでに存在する住所データの場合は、関連付けだけ変更する

等のちょっとした工夫が必要になってきます。

もちろん、solidusはここらへんの処理もいい感じに組み込まれています。色々と考えられていますね。

-モデリング