私はコンサルティング会社のような会社で働いています。 1つのクライアント用に作成したWebアプリケーションがあります。現在、約30の他のクライアントがほぼ同じ製品を求めています。問題は、データをどこに置くかわからないことです。ほとんどのデータはトランザクション対応であり、すべてのクライアントが現在のスキーマに適合できます。問題は、ほとんどのクライアントがSQLに堪能で、自分のテーブルにアクセスできるようにしたいということです。各クライアントのデータを同じテーブルにスローすると、テーブルへのアクセス権をだれにも与えることができなくなります(データは非常にプライベートであり、共有できません)。だから私は箱から出して考えようとしています。
ここでの他の回答に基づくと、各クライアントに独自のテーブルを与えることは賢明ではないようです。各クライアントに独自のデータベースを与えるのはどうですか?それからどんな落とし穴が来るかもしれませんか?
SQLへのクライアントアクセスを許可しないでください。代わりにAPIを提供してください。
アクセスを許可したい場合は、データベース技術者に応じていくつかのソリューションがあります
それぞれ1つのデータベース。
これが最も簡単な解決策です
行レベルのアクセス制限
テーブルを複数のスキーマに複製し、スキーマレベルのアクセス制限を設定する
あなたも言う:
データは非常にプライベートであり、共有できません
完全に別のデータベースを使用します。これは、データの分離の最高レベルを提供し、アクセス制限の観点から最も簡単なアプローチです。
もちろん欠点は、複数のデータベースと、おそらく複数のアプリケーションインスタンスがあり、それぞれが独自のデータベースをポイントしていることです。
特定の理由がない限り、データベースを分割している場合は、マルチテナントアプリを使用しません。特別な理由がなければ、すべてのデータベースへの単一のアクセスポイントが効果的に提供され、分離が損なわれます。
これが機能するかどうか、またはどのように機能するかは完全にはわかりませんが、おそらく1つのデータベースと1つのメインテーブルセットを用意し、各ユーザー/インスタンスの各テーブルに一意のビューを作成できます。そのユーザーのビューへのアクセスのみを許可します。ビューは、ユーザーが返すデータを、そのユーザーのデータのみを返すように制限します。
(あまり便利な答えではありませんが、コメントする評判はまだありません)
他の人が示唆したように、情報の機密性についてあなたが言ったことを踏まえて、ユーザーごとに個別のデータベースを作成します。
また、誤ったSQL操作でDBのコンテンツを破棄できないように、読み取り専用アクセスを付与することは理にかなっていますか?