SQLServerとHibernateによるスキーマベースのマルチテナント

Question

私は、データベースとしてhibernateとSQLServerを使用してマルチテナントソリューションを実装することに興味があります。 私は1つのデータベースと異なるスキーマを意味するスキーマベースのアプローチを使用しています。

具体的には、私の質問はSQLServerで実行スキーマを変更する方法です。私はこのアプローチをMySQLで使用しましたuse $database、 PostgreSQL SET search_path TO $schemaとOracle ALTER SESSION SET CURRENT_SCHEMA = $schema私はスキーマの概念がデータベースごとに異なることに注意して、あるスキーマから他のスキーマに正常に切り替えることができました。

しかし、SQLServerでは、実行スキーマを変更することはできません。ユーザーにsysadminロールが与えられていない場合に備えて、特定のユーザーの既定のスキーマを切り替える可能性を認識しています。また、次のクエリを使用して偽装の概念を認識しています：EXECUTE AS USER = $user偽装により、あるユーザーが他のユーザーを偽装することができ、現在のユーザーを変更する可能性があります。

現在のユーザを切り替えると、ユーザが変更されると実行スキーマが新しいユーザのデフォルトスキーマになるため、定義によって実行スキーマを切り替えることができます。ただし、偽装は32回にわたって実行できないため、偽装には制限があります。制限偽装番号に達するのを避けるために、各偽装後にrevertを実行することは可能ですが、この解決策は私の場合は適切ではありません。代わりに

SQL Serverとスキーマベースのアプローチを使用しているマルチテナントの実装についての提案はありますか？

実行スキーマを切り替えるために私が言及したもの以外の解決策もあります。

ご協力いただきありがとうございます。ありがとうございます。

Answer 1

次は、SQL Serverが[DBO]のようなテーブルの接頭辞によって、スキーマのを区別します。[ユーザー]および[Tenant01]。[ユーザー]

ますので考慮

1. ためのポイントですSQL Serverの各スキーマのデータベース接続を解決する方法については言及していませんが、私はあなたのユースケースをサポートするAzure Shard Mapを見てみることをお勧めします。確立されたテナントコンテキストに基づく集中化されたストアからの接続文字列。例：Tenant01はConnectionString C01にマップされますが、これは同じデータベースを持ちますが、異なるユーザーIDとパスワードを持ちます。このアプローチは、より一般的な方法です。しかし、Azure Shard Mapを選択することもできます。Azure Shard Mapは、このマッピングをあなたのためにバックグラウンドで行います。
2. この場合、スキーマをプロビジョニングするときは、SQLユーザーを作成するか、スキーマにAzure ADユーザーをマップし、スキーマに必要なアクセス許可を与えます。これにより、アクセスが良好であることが保証されます。

上記のテナントワイズ接続文字列をストアに保存すると、データの量が膨大になるため、特定のテナントをShared DBからスケールアウトする場合に役立ちます残りのテナントにとってより良いパフォーマンスを提供します。代わりに、Azureのシャード地図

EDIT実際

、あなたはSQL Serverのスキーマにマップされたユーザーを持っている場合、クエリで[Schema].[Table]を使用する必要はありませんが、上の

Moreあなたは直接[Table]を使用することができます、アクセスは自動的に発生します。実際にはALTER USER erpadmin WITH DEFAULT_SCHEMA = erpadmin;のようなものを使用してユーザーをスキーマにマップすることができますが、クエリにはテーブルのプレフィックスプレフィックスは必要ありません。詳細here

HTH