博士

やあ、ロボ子。今日はSaaSのマルチテナントデータモデリングについて話すのじゃ。

ロボ子

博士、マルチテナントデータモデリングですか。複数のユーザーを分離して管理することですよね。

博士

そうじゃ、ロボ子。SaaS構築者は最初から「チーム」機能を組み込むべきなのじゃ。後から追加するのは大変だぞ。

ロボ子

なるほど。記事にも「ソフトウェア開発において、人間関係のモデリングは重要」とありますね。

博士

その通り！データベース設計の基本は、シングルデータベースで、特別な場合にのみデータベース/ユーザーを検討するのじゃ。

ロボ子

最上位モデルの名前は、Organizationを推奨とのことですが、何か理由があるのでしょうか？

博士

ふむ、Organizationは、Account, Team, Company, Tenant, Workspaceよりも一般的で、意味が広いからのじゃ。

ロボ子

アクセスモデルには、GitHubモデル、Googleモデル、Linearモデルがあるんですね。LinearモデルがほとんどのB2Bスタートアップに最適とのことですが。

博士

Linearモデルは、GitHubとGoogleの利点を組み合わせたものなのじゃ。ユーザーは単一のアカウントで複数のOrganizationにアクセスでき、Organizationごとに別のアカウントを持つこともできるぞ。

ロボ子

個人アカウントは単一ユーザーのOrganizationとして扱う、という考え方は面白いですね。

博士

じゃろ？リソースの所有権は、ほとんどの場合Organizationに属するのじゃ。

ロボ子

ユーザーとOrganizationの関連付けには、Organization、Membership、Userテーブルを使用するんですね。Membershipテーブルは、ユーザー、Organization、ロールを関連付ける、と。

博士

そうじゃ。データ分離が最重要で、データベースのすべてのテーブル（ユーザーを除く）に`organization_id`を追加するのじゃ。

ロボ子

URLを含むすべての場所にOrganization IDを含めることも重要ですね。`/org/[orgId]/projects/[projectId]`のように。

博士

その通り！ユーザーログインセッションも重要じゃ。基本的な実装では、ユーザーセッションに`organization_id`を保存するのじゃ。

ロボ子

新規ユーザーサインアップ時には、User、Organization、Membershipモデルを作成し、リンクするんですね。

博士

Organizationへのユーザー招待には、Membershipモデルを招待として使用するのじゃ。`invitationId`、`invitationExpiresAt`、`invitedEmail`フィールドを使うぞ。

ロボ子

ロールベースアクセス制御（RBAC）では、Membershipは`role`または`roles`フィールドを持つんですね。

博士

`Organization`は課金を管理する場所じゃ。`Organization`に`billingEmail`と`stripeCustomerId`を持たせるのじゃ。

ロボ子

設定もOrganization、ユーザー（Organizationごと）、グローバルの3つのレベルで管理するんですね。

博士

分析では、`group`の概念を使用して、複数の`userId`を単一のOrganizationにリンクするのじゃ。Segmentを使う場合は、`groupId`を`orgId`に設定するぞ。

ロボ子

高度な追加機能として、Organizationタイプや親子関係、メンバーシップなどもあるんですね。

博士

ふむ、今日はここまでじゃ。最後に一つ、ロボ子。SaaSのデータモデリングは、まるで複雑な人間関係みたいじゃな。でも、ちゃんと設計すれば、うまくいくぞ！

ロボ子

博士、ありがとうございました。でも、人間関係はデータモデリングよりも予測不可能だと思います…。

博士

あはは、確かに！でも、データモデリングもバグだらけになると、予測不可能になるかも…！