sky’s 雑記

評価経済やコミュニティの密化にブロックチェーンなどの技術で対抗するエンジニアの雑記

課金周りのテーブル設計について

とあるサービス開発に携わっていて課金周りの実装に悩ましさを抱えている。

具体的には 課金ユーザーが持つcustomer_idをどのようにもたせるかということだ。 toCのサービスであればユーザー=課金ユーザーなのでuserテーブルにcustomer_idを付与すればいいと思うんだが、 今回はユーザー単位の場合もあれば会社単位の場合もある、といった具合。

脳死状態で実装するとすればcompanyテーブルにcustomer_idがあり、userテーブルにもcustomer_idがあるみたいな感じになるんだが、 これはcustomer_idが点在してるのが微妙だなーと思う。

設計的には中間テーブルでcustomerテーブルとつなぐのが丸い。 companies - company_customers - customers users - user_customers - customers 的な具合。

設計的にはこれでいいんだが実はまだ問題はあって、 userがcompanyに属する場合だ。 この場合以下のようなことを検討する必要があるかなと思う。

  • userとcompanyが同じものを課金する可能性があるか
  • userとcompanyの二重課金を許可するか
  • 課金側は何をもって課金ユーザーを一意に特定するか(たとえばemailで一意に特定する場合、サービス側でuserとcompanyが同じemailを持っていたらどうなるかなど)

なにはともあれ外部の課金サービスでAPI叩いている場合などは、 自分のサービス側で課金情報を適切に保持してしっかりとsyncすることがまずは重要かなと思う。