
ECサイトのモデリング(住所編)
システムエンジニアの村上です。
入社してもう半年が過ぎました。
ここ半年間のほとんどは、社内のECサイトの開発を行ってきました。
弊社のECサイトは、railsのECサイト構築フレームワークspreeの後衛「solidus」を使用しています。
solidusは、なかなか大きいオープンソースですが、実際にECサイトを運営する上で必要な機能が十分に組み込まれていて、
ドキュメントも豊富なので、railsエンジニアなら一度目を通しておいて損はないかと。
そして、データモデリングに関しても参考になるところが多かったので、
solidusをベースに、ECサイトのモデリングについて解説していきます。
今回は住所周りです。
住所の仕様
- 会員情報を保持するユーザーテーブル
- 商品購入の際に必要となるデータを保持する注文テーブル
が存在するとして、
住所情報の用途から考えていきます。
ECサイトなので、購入した商品を配送するための配送先住所が必要になります。
この配送先住所は注文データ単位で登録していきます。
また、注文するたび、住所を一から入力するのは親切ではないので、事前に登録した住所情報を使えるようにすると、
ユーザー自体にも住所情報を持たせる必要も出てきます。
モデリング
単純にユーザーテーブルと注文テーブルそれぞれに住所情報を持たせると、
都道府県、市町村、番地、建物名、郵便番号などのカラムがそれぞれのテーブルに作られます。
この場合、注文データの配送先住所をユーザーの登録済み住所を元に登録する際、カラム一つ一つに格納していかねばならないですし、
そもそも正規化されていないので、共通の住所情報を新たに住所テーブルとして抜き出します。
すると以下のような構造になります。
上記の構造だと、
注文データの配送先住所に、ユーザーの登録済みの住所を利用したいときは、
ユーザーと紐付いている住所レコードを、該当の注文レコードにも紐付ければ良いだけです。
また、注文データに配送先住所とは別に請求先住所を加える場合も、外部キーを1つ追加するだけで済みます。
ただし、ちょっとした工夫が必要
注文データとユーザーが住所テーブルを共有する場合、それぞれ同じ住所レコードを参照している可能性があります。
この状態で、ユーザーが住所情報を変更してしまった場合は、住所データの住所情報も変更されてしまいます。
実際にECサイトを運営していて、注文時に登録した住所が勝手に変更されてしまったら、大変ですよね。
ですので、
- ユーザーが住所情報を更新した場合は、新しく住所レコードを作成して、新しい住所レコードとユーザーを紐付かせる
- 一度作成された住所レコードは更新不可(ReadOnly)にする
- 同じ内容の住所レコードが作成されないように、住所更新or新規作成の際は既存のレコードを確認し、すでに存在する住所データの場合は、関連付けだけ変更する
等のちょっとした工夫が必要になってきます。
もちろん、solidusはここらへんの処理もいい感じに組み込まれています。色々と考えられていますね。
- ECサイトのモデリング(住所編) - 2016-08-30