SaaSを提供するとして、企業や組織ごとにサービスの切り分け方について（BtoBtoC）具体的方法をお教えください。

Question

###前提・実現したいこと
PHPやJavaやその他色々でサービスを作っています。

サービス提供のログインなどの切り分け方で
皆様はどのような考えと具体的設計・実装をされているのか、
この初心者に対してお教え頂ければ幸いです。

###例

A:
普通のコンシューマー向けサービスならBtoCとして、超簡単に考えると、
個人のIDだけでユーザー画面を割り振るだけで大丈夫だと思います。

B:
あるサービスを沢山の顧客へ提供する（セールスフォースやConfluenceなど…）となると、
BtoBtoC（Cは企業の中の個人としての表現）になってくると思います。

Bの場合で、サービスの設計と具体的実装などの調べたリ勉強したしたりしたのですが、
お恥ずかしいですが、具体的にはわからずじまいです。

「A」ですと超簡単に考えればテーブル１つ（ユーザーテーブル）ぐらいですみますよね？
「B」ですとテーブル２つ？（企業テーブル・ユーザーテーブル）で考える？もしくは、サブドメインで切ってしまう？などなど…

###環境
AWSなどの仮想サーバーorさくらVPSなどの仮想環境下で提供すると仮定します。

できるだけ具体的にお教え頂ければ幸いです。

既出かもしれませんがどうぞお手柔らかによろしくお願いいたします。

Answer 1

サービスの要件によりケースバイケースになる内容なので、
質問の範囲としては少し広すぎるように思います。

推奨していない質問

問題・課題が含まれていない質問

teratailは困っている人の質問を解決するサービスです。そのため、漠然とした興味から票を募るような質問や、意見の主張をすることを目的とした投稿は推奨していません。
何か困っている理由があり、最適解を見つける為の知見を得たい場合は、その理由や何が知りたいのかを明確に記述してください。

の後半部分をご確認下さい。

様々なケースを具体的に知りたいという事であれば
WEB+DB PRESSや等のバックナンバーからケースを洗い出してみると言うようなアプローチが効率がいいと思います。
総集編がとても安いです。
Software Design総集編も素敵です。

これだけだとあれなので、
質問にある例のケースですと、

「A」ですと超簡単に考えればテーブル１つ（ユーザーテーブル）ぐらいですみますよね？

はい。シンプルなケースだとそうなります。

「B」ですとテーブル２つ？（企業テーブル・ユーザーテーブル）で考える？
もしくは、サブドメインで切ってしまう？

どちらでも実装可能で、ケースバイケースになります。
どちらのケースも実装したことがありますが、

• 前者はコストパフォーマンスや利便性、保守性に優れる。
• 企業が増えてもレコードを増やすだけなので即時対応できる
• バグや脆弱性によって他企業のデータが見れてしまったりする可能性が常にある
• 一部企業の利用状況が全体のパフォーマンスに影響を与える
• 企業単位のアップデートやカスタマイズは原則として出来なくなる（全体の機能としてプラグインや機能On/offなどをつけるというのは可能）

後者（企業単位でDBを分けてしまう）はその逆で、

• コストパフォーマンスや納期の問題が出てくるが、原理的にセキュリティが一段高くなったりする
• メンテナンスを企業毎の事情に合わせることが出来る

という感じになりますね。

Comments

[DANGANMARU]

tanat様

ご指摘ありがとうございます。
次回から注意いたします。

また、両者（A/B）に対してご回答も大変感謝します。
正直ユーザー単位ログインに対して、結局テーブルやデータベースなどの切り分け方って今後導入するにあたってレガシーすぎるんじゃないかと不安がありました。ある「仕組み」を使えば意外とあっさりこの部分が晴れるような気がしてしまい、こんな漠然とした質問に至りました。
ひとまずRubyであれ、JavaやPHPであれ、基幹システムに大幅な違いが無いことを考慮すると、ひとまず今の考えで行こうかと思います。

ありがとうございました。