web-dev-qa-db-ja.com

スキーマとテーブルスペースの理解-レイヤー分離の推奨

DLDR：取得したい

  • テーブルスペースとスキーマについての私の理解の確認（画像を参照）
  • スキーマとテーブルスペースを整理して、後で簡単に分離できるようにするための推奨事項。

背景：私たちのプロジェクトには、Webサイトの実装に取り​​組んでいる2つの異なるチームがあります。アイデアは、後で_basic-services_をwebsite (cms / portal)から分離して、異なるWebサイト/ポータルを作成できるようにすることであり、すべてが同じ独立した_basic-services_を使用しています。

現在のインストールは次のようになります。

_TABLESPACE_N  MB  AUTOEXTENSIBLE
FOOBAR_DATA    1024       YES 
FOOBAR_INDEX   1024       YES 
FOOBAR_LOB     1024       YES 
SYSAUX         600       YES 
SYSTEM         700       YES 
TEMP          1024       NO
UNDOTBS1       456       YES 
_

これは 質問はスキーマを別のテーブルスペースに移動する方法についてです 。一部の推奨事項_store indexes in another filesystem_は 物議を醸す/問題がある です。しかし、これは私の質問の範囲ではありません。スキーマとテーブルスペースを整理して、後で簡単に分離できるようにするための推奨事項を教えてください。

確認/明確化：Oracleの私の理解は次のとおりです：

  • Tablespace：論理ストレージユニット、1つ以上のデータファイル
  • データファイル：OSに準拠する物理構造、データファイルは1つのテーブルスペースと1つのデータベースのみに関連付けることができます
  • スキーマ：データの論理構造のコレクション（テーブル、インデックス）、またはスキーマオブジェクト（ビュー、..）、db-userと同じ名前それはそれを所有し、各ユーザーは単一のスキーマを所有します。 [ユーザーには、さまざまなUSERSが所有するスキーマオブジェクトへのアクセス権が付与される場合があります。]

Oracle tablespaces, datafiles, schema and tables

添付画像では、2つのスキーマを確認できます。

  • 白いスキーマ_S1_
  • 黄色のスキーマ_S2_

質問1：

  1. スキーマがデータベース内でどのように編成されるかについての私の理解は正しいですか？
  2. したがって、2つのスキーマ（/ 2人のユーザー）を作成し、_FOOBAR-services_（黄色）のオブジェクトを_FOOBAR-website_（白）から好きなように分離できますか？
    • スキーマ1では、データファイル1および2でのみテーブルスペース1を使用できますか？
    • スキーマ2では、データファイル3でのみテーブルスペース2を使用できますか？

質問2：

_FOOBAR-website_と_FOOBAR-services_を後で簡単に分離するためにどの構造を推奨しますか

  • _FOOBAR-Web_と_FOOBAR-Services_の異なるテーブルスペース？
  • 独自のテーブルスペース（またはnスペース）内の各スキーマ？
oracleschematablespaces
2
threeFourOneSixOneThree

これは複雑すぎると思います。権限とロールは、データが置かれているテーブルスペースとデータファイルではなく、ユーザーによるアクセスを制御します。はい、スキーマに独自のテーブルスペースがある場合、バックアップ、リカバリ、エクスポートははるかに簡単ですが、それはあなたの質問ではないようです。

  • ユーザー/スキーマごとにビジネスドメインを分離します。
  • 各ユーザー/スキーマに、それらのテーブル/インデックス/ LOBを含む独自のテーブルスペースのグループを与えます。例：User1Data、User1Indexes、User1LOBS
  • ユーザー/スキーマが他のスキーマのデータ/コードにアクセスできるようにするロールを作成する

以下のあなたのコメントから私は追加します：

  • ユーザー/スキーマは、データとコードを分離する論理的な方法です。ビジネスドメインがそのように機能する場合は、初日とは異なるスキーマを使用します（そして、それが示しているように思われます）。展開後にテーブルを別のスキーマに移動することはできますが、それは面倒です。
  • コメントでは、引き続きテーブルスペースと権限をリンクします。ユーザーのデータが含まれているテーブルスペースと、そのデータに付与されている権限との間にリンクはありません。

あなたが私を単純化できるようにするならば：

  • ユーザーとスキーマを使用すると、ロールと付与を通じてデータとコードへのアクセスを制御できます
  • テーブルスペースとデータファイルを使用すると、データベースで使用される物理ファイルを管理できます。より簡単なバックアップとリカバリーは、各ユーザーが明確に定義された表スペースのセットにデータを持っている場合に実行しやすいことの1つです。
4
kevinsky