0

これらは両方とも私のアプリで機能します：

INSERT INTO PLATYPUS (Bla, Blee, Bloo, Blah) VALUES (:Bla, :Blee, :Bloo, :Blah)

INSERT INTO CRITTERS.PLATYPUS (Bla, Blee, Bloo, Blah) VALUES (:Bla, :Blee, :Bloo, :Blah)

...一方の方法がもう一方の方法よりも優先されますか？

4

4 に答える 4

3

複数のスキーマを使用している場合は、いいえ。それはすべてコンテキストに関するものです。明示的は暗黙的よりも優れています。

于 2012-08-02T16:51:03.943 に答える
2

デフォルトのスキーマがCRITTERSであるユーザーとしてログインしている可能性があるため、どちらも機能します。デフォルトのスキーマが異なるときに別のユーザーとしてログインする場合は、修飾された形式のクエリを使用する必要があります。

于 2012-08-02T16:50:42.123 に答える
2

暗黙的および明示的（私はそれらを「ハードコーディング」と呼びます）スキーマ参照の両方を使用した多くのシステムで作業した後、すべての場合において、アプリケーションコードでスキーマ名をハードコーディングすると生活がより困難になることがわかりました。

これが、Oracleに同義語がある理由です。

スキーマ名をハードコーディングするのは、展開スクリプトでのみです。たとえば、オブジェクトを作成するときに、オブジェクトを作成するスキーマを明示的に指定します。

これは、開発者が「同じインスタンスに開発データベースのコピーを作成できますか？」と尋ねると、「問題ありません。数分待ってください」と言うことができます。新しいスキーマを作成し、テーブルなどをそのスキーマにコピーしてから、ログインユーザーの同義語を更新して新しいスキーマを指すようにします。出来上がり、1つのインスタンスに2つのデータベース。ただし、アプリケーションコードにスキーマ名をハードコーディングさせると、同義語の変換が行われないため、これは不可能になります。

于 2012-08-08T06:07:44.073 に答える
1

Oracleアプリケーションの最初のステートメントは、アクセスするオブジェクトを明示的に示すことです。

alter session set current_schema = MYSCHEMA;

このようにして、1つのデータベースサーバー（インスタンス）内のさまざまなスキーマ（データベース）にアプリケーションを指定できます。したがって、スキーマアカウントとしてログインしないでください。スキーマアカウントはロックする必要があり、ddl-changes（アップグレード）中にのみ開く必要があります。

私が放送局であり、RTL1、RTL2、RTL3、RTL4などの複数のチャネルを実行しているとします。同じアプリケーションがデータベースサーバー内の異なるデータベース（Oracle用語スキーマ）にログオンできます。

次に、RTL1用のアプリケーションを実行します。

alter session set current_schema = RTL1;
select * from top_stories;

次に、RTL2用のアプリケーションを実行します。

alter session set current_schema = RTL2;
select * from top_stories;

等...

私が目にする一番の設計上の欠陥は、1対1の関係です。アプリケーションとデータベースサーバーです。これにより、管理、ストレージ、およびバックアップがフルタイムの仕事になります。Oracleは、1つのデータベースサーバーで数千のアプリケーションとデータベース/スキーマを実行できます。

しかし、いつものように、それは異なります。1つのデータベースサーバーで1つのアプリケーションを実行することが理にかなっている場合があります。

そのため、どのスキーマにもインストールされるようにアプリケーションにプレフィックスを付けて設計しないようにしています。他のスキーマのオブジェクトにアクセスする必要がある場合は、ビューやシノニムを利用します。

このアプローチは非常にうまく機能しており、クエリを実行してアクセスしているオブジェクトを把握しています。

select sys_context('USERENV','CURRENT_SCHEMA') from dual;
于 2012-08-02T19:43:56.623 に答える