私の質問はかなり簡単です：
複数の企業に導入されるシステムを開発しています。ある会社のデータを別の会社に分けるために、すべてのテーブルでフィールドを使用したくありません。よりスケーラブルなソリューションを使用したいと考えています。
私のアイデアは、単一のデータベース スキーマをモデル化し、システム内のインスタンスごとにその「インスタンス」を作成して、単一のデータベースまたは基本スキーマをバックアップし、基本スキーマを変更するだけですべてのスキーマの変更を伝達することです。つまり、基本スキーマまたは物理スキーマが 1 つだけ存在し、そのスキーマの多数のデータ インスタンスが一意のスキーマ名で参照されます。
これは可能ですか？この技術は何と呼ばれていますか？(私はこの概念を初めて使用します) IBM DB2 にどのように実装しますか?
私があなたのことを正しく理解していれば、それは不可能だと思います。実用的でないことは確かです。
列とその列のインデックスを基本スキーマに追加することを想像してください。多くのデータを持っていないある会社では、その変更はかなり些細なことです。しかし、何百万もの行を持つ企業では、突然ディスク容量が不足することがあります。
DBAは、インデックスまたはテーブルを別のディスクまたは別のファイル システムに移動することでこの問題に対処できますが、データベースがベース スキーマから「インスタンス化」されている場合、それは不可能な場合があります。( DB2 固有の意味と、より一般的な OOP の意味を持つinstancedの意味によって異なります。)
あなたが探している用語は、「マルチテナント」だと思います。(ここでは、テナントと顧客はほぼ同じ意味です。) SO には「マルチテナント」タグがあります。追加しますが、不適切な場合は削除してください。IBM の developerWorks ライブラリーには、さまざまなマルチテナント・アーキテクチャーに関する入門記事があります。
マルチテナント アーキテクチャは、「何も共有しない」(各テナントが独自のデータベースを取得する) から「すべてを共有する」(すべてのテナントが 1 つのデータベース内のテーブルを共有し、各行には、その行を「所有」するテナントを識別する列がある) までの範囲があります。 .
「何も共有しない」と「すべてを共有する」の間に「共有スキーマ」があります (テナントはデータベースを共有し、各テナントはプライベート スキーマを持ちます)。
最も明白な違いは、カスタマイズ、災害復旧、およびデータ分離です。これらの違いは、アーキテクチャの選択にも影響します。
「何も共有しない」ため、カスタマイズが容易になります。データベースを変更しても、他のテナントには影響しません。災害復旧も簡単です。バックアップからデータベース全体を復元するだけです。ほぼ完全に分離するために、権限をデータベース レベルで適用できます。
「すべてを共有」すると、カスタマイズが難しくなります。すべての変更は、すべてのテナントにある程度影響します。災害復旧も困難です。単一の会社の災害の場合、いくつかの行 (単一の会社が「所有する」行のみ) をすべてのテーブルに復元する必要があります。展開するすべてのビューとクエリがテナント識別子を正しく説明する必要があるため、データの分離も難しくなります。それを一度でも忘れてしまえば、廃業するかもしれません。