BtoBtoC(BtoBtoBでも可)向けのアプリの場合、そのアプリを提供している会社向けに管理画面を提供したいと考えることがあります。その管理画面では、利用企業が自分たちのデータについてだけメンテナンスできるようになります。
この時、幾つかの選択肢があります。
- 利用企業ごとにアプリケーションキーを分ける
- クラス名を分ける
- ACLで管理する
利用企業ごとにアプリケーションキーを分ける
アプリケーションキーを分けるのは、企業ごとに提供するアプリが異なる場合に使えます。ベースになるアプリがあって、OEMとして各企業向けにアプリをカスタマイズして提供する場合です。旅行ガイド、不動産、飲食店向けなど画像やカラーテーマを変えて水平展開するアプリに使えます。
この場合のメリットは別な企業のデータを誤って閲覧したり、更新したりすることが発生し得ないことです。アプリケーションキーとクライアントキーが別な物であれば、決して混じることはないでしょう。
デメリットとしてはデータの一元管理ができないために運用時に若干面倒になります。契約する企業が増えると、アプリケーションキーの管理も煩雑になってきたり、アプリ名の付け方をあらかじめ決めておかないと、一見しただけではどの企業のものなのか分からなくなってしまいます。
クラス名を分ける
mBaaSでは存在しないクラス名でデータの保存を行うと自動的にクラスの作成とデータ保存を行ってくれます。この特性を使って、企業ごとに異なるプリフィックス(またはサフィックス)をつけることで、データの混在を防げるようになります。例えば次のようになります。
- AAA_Setting AAA社向けの設定情報が入ったクラス
- AAA_Data AAA社向けの管理データが入ったクラス
- BBB_Setting BBB社向けの設定情報が入ったクラス
- BBB_Data BBB社向けの管理データが入ったクラス
メリットとしてはアプリケーションキーを分けるのと同様にデータの混在が起こりえないことになります。もちろんプログラム中ではこのプリフィックス(サフィックス)を意識してクラス名を定義しなければなりません。また、AAA/BBBといった識別子がついていれば一覧で見た時にもどの企業のデータなのか分かるようになります。
デメリットとしては契約企業数×クラスの数だけ合計のクラス数が増えてしまうことです。関連クラスが4つだったとしても、契約者数が100あればクラス数が全部で400個になってしまいます。
ACLで管理する
ACLでデータを管理する場合、メリットは一つのアプリケーションキーだけで管理できることです。さらにクラスも必要最低限の数で済みます。一つのクラスの中にすべての企業データが入るので管理はしやすくなります。
デメリットは運用が若干複雑になるということです。まずデータは実際のアプリ利用者(消費者)が見えなければなりません。ユーザ登録必須であれば良いのですが、そうでない場合は全体への読み取り権限はつけておく必要があります。ただし、AAA社のデータがBBB社に見えてしまうのは問題がありますので、データを取り出す際にクエリで絞り込む必要があります。
データの更新についてはACLで制限されていますので別な企業のデータを更新してしまうことはないでしょう。つまりデータの作成時に適切にACLを設定しておく必要があります。そしてデータを一覧しただけではどの企業のデータか分かりませんので、企業名を一つのフィールドに追加しておく方が良いでしょう(データの絞り込みにも利用)。
さらにデータストアに大量のデータが入ると一覧の取得などが遅くなってしまいます。そのため、データを配列やオブジェクトとして保存することでレコード数をなるべく少なくするようにしましょう。そうすることで一社が大量のデータを投入したことによる影響を抑えられるようになります。なお、データを配列やオブジェクトにすると検索や集計に影響を及ぼすことがありますので、上記クラス名を分けると併用しても良いでしょう。
今回は概要を説明しました。次回以降、実際に簡易的な画面を作ってみたいと思います。なお、アプリケーションキーとクライアントキーが契約企業に見えてしまうと大きな問題なので、Webアプリケーションとして提供することにします。