大きなアプリケーションのために、同じデータベースの異なるスキーマのテーブルに外部キーを作成するのは悪い考えですか？

13

私は大きなpl / sql Webベースのアプリケーションを専用サーバーに転送する作業をしています。このアプリケーションは、プログラムコードの70パッケージを含む1つのスキーマにあります。このアプリケーションは、さまざまな時期に約15人で作成されました。また、異なるスキーマの参照テーブルに外部キーを作成することは通常の習慣でした。異なるスキーマに同じ参照テーブルを保持する必要がないため、本当に便利でデータベースを非常にクリーンに保つためです。

しかし、とにかく私のDBA（DBを使用して新しいインスタンスを作成し、Solarisゾーン内にアプリケーションをコピーした）は、今日、「異なるスキーマの外部キーは悪で、破壊する必要があります！」彼は自分の見解を説明しなかった。

大きなアプリケーションでそれを行うのは本当に悪い考えですか？

— アレクサンダー・ミショフ
ソース

13

DBAを解雇する必要があります。

— コリン 'ハート

1

DBAは彼らの言うことならすべてバカだと叫びますが、DBAの議論には他の文脈がなかったと確信していますか？

— カーミット

1

DBAは、開発者がこのことを構築する際に行ったばかげた仕事をサポートするために、できる限り最善を尽くしているだけかもしれません。

— swasheck

2

@swasheck一方、データベースがこのDBAの下で数年間の矛盾を蓄積した後、彼の仕事をしたいですか？

— きらめき

@Twinklesまったくない

— スワッシュック

6

Bearwith me-私はSQL Serverから来ましたが、神託は嫌いですが、議論はまだ続いていると思います。

スキーマは、論理サブシステムからテーブルを分離するのに適しています。外部キーはデータの整合性を保証します。これらは直交する概念です-サブシステム間のデータ整合性も明らかに必要であるため。アカウンティングと出荷、および場合によってはセントラルCUstomerデータは、顧客がアカウンティングで使用されている間に削除されるサイロに存在しません。

そのため、DBAの要件は無能の兆候だと思います。誰でも介入して反論を提供してください-私は幸せです。しかし、これがSQL Serverでの方法です（ただし、スキーマの定義はIIRCであり、oracle定義とは少し異なります）。

— トムトム
ソース

4

詳細な推論なしに外部キー制約の破棄を要求するのは愚かですが、外部参照を制御下に置くことは理にかなっています。参照しているスキーマの名前が新しいサーバーで異なる場合はどうなりますか？

Oracleでは、現在のスキーマの外部にあるオブジェクトに対してSYNONYMSを作成することにより、この問題を解決します。

— きらめき
ソース

1

シノニムを使いすぎて、「これが何を指しているのか」という疑問をさらに曖昧にすることができます。セキュリティ、パフォーマンスとベストプラクティスの詳細についてはこちらをご覧くださいstackoverflow.com/a/10042117/851930

— kevinsky

3

シノニムを外部キー制約のターゲットとして使用することはできません。

— コリン 'ハート

有効なポイント。そして、他の人にメリットと危険性を主張する機会を与えずに発言することは悪いことのさらなる証拠。

— きらめき

2

スキーマを別のデータベースに移動する必要がある場合（スペース/セキュリティ/その他）、参照を処理できなくなります。それがおそらく参照の削除を要求する主な理由です。

— AMG
ソース

0

これから想像できる唯一の「悪い考え」は、ロールにREFERENCESオブジェクト権限（テーブルを参照する制約を作成するために必要な権限）を付与できないことです。スキーマ/ユーザーごとにスキーマ/ユーザーを実行する必要があります。

それに加えて、私はあなたのDBAのポイントを見ていません。

— ベガトリピー
ソース

0

考えてみてください：子テーブルの所有者スキーマはテーブル内にレコードを作成し始め、親テーブルスキーマユーザーが親テーブルからレコードを削除することを知らずに防ぎます。それは予想し、感謝するものですか？

— letron123
ソース