2

ソフトウェアソリューションの顧客が多いほど、スキームに含まれる個々のOracleオブジェクト（テーブル、パッケージ、関数など）が増えます。今のところ、「X_CUSTOMER1_TABLENAME」のような識別名を付けることでこれらを分離しています。例：（私は知っています..... :-(）

これは、参照をクリーンに保つ場合、および参照を顧客データベースとデプロイ/同期する場合にはあまり実用的ではありません。ある顧客は、デプロイ時に他の顧客のオブジェクトを受け取ります。

この問題に対する一般的な解決策はありますか？私たちは、顧客ごとに個別のスキームを用意することを考えていました。そうすれば、基本的な機能を備えた標準の手つかずのスキームと、個々のコンテンツを備えた顧客スキームが得られます。

もう少し具体的に言うと、ソフトウェアのコンテンツ/機能を最大限に活用する基本的なテーブルが約100あります。各顧客は、個々のパッケージ、関数などの標準オブジェクトと組み合わせて使用​​される「カスタム」データを含む1〜5の追加テーブルを持っている場合があります。ほとんどの場合、この顧客だけがこれらの1〜5のテーブルを持っています（たとえば、会社固有のコンテンツ）。他の会社には意味がありません）。

ヒントやベストプラクティスをいただければ幸いです。これは、昔ながらのリレーショナルデータベースです。

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

4

1 に答える 1

2

私はOracleで20年以上の経験を持つOracleDBAなので、「オールドスクール」になります。各顧客に独自のスキーマを提供することをお勧めします。物事をより管理しやすくします。-スキーマごとのアクティビティの追跡（課金目的）-oracleは、スキーマごとのI / O、CPU、およびスペース消費量に関する統計を提供します-スペース使用量の追跡（スキーマを独自のテーブルスペースに配置する場合）-ユーザーを1つのデータベースから簡単に移動できます別の（成長のために）-顧客が離れるとき、スキーマをバックアップしてドロップします-バックアップをより適切に管理し、アクティブなアカウントをより頻繁にバックアップし、アクティブでないアカウントをより頻繁にバックアップすることができます。他にも正当な理由があるかもしれませんが、この短いリストで十分かもしれません。App共通テーブルは独自のスキーマに配置されますが、このスキーマには読み取り専用テーブルのみを配置します。顧客によって変更されるテーブル、彼らのスキーマに入ります。請求とセキュリティのために、マスターテーブルlist_of_customersを作成できます。ただし、AppBus管理者のみがアクセスできます。

于 2012-11-25T21:30:10.210 に答える