タグ付けされた質問 「foreign-key」

RDBMSプラットフォームで使用される整合性制約の一種で、列の値が別のテーブルのキー値の範囲の1つと確実に一致するようにします。

2
指定された主キーに関連付けられた外部キーを見つける
特定のデータベースのどの列がPK / FK関係を介して結合されているかを確立する方法が必要です。特定のテーブルのPK / FK情報を返すには SELECT * FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE AS cu WHERE EXISTS ( SELECT tc.* FROM INFORMATION_SCHEMA.TABLE_CONSTRAINTS AS tc WHERE tc.CONSTRAINT_CATALOG = 'MyDatabase' AND tc.TABLE_NAME = 'MyTable' /*AND tc.CONSTRAINT_TYPE = 'PRIMARY KEY'*/ AND tc.CONSTRAINT_NAME = cu.CONSTRAINT_NAME); GO しかし、そのようなクエリから返されたPKの場合、関連付けられたFKを確立するにはどうすればよいですか（1つがある場合）。 参照されたテーブルは次の方法でも取得できます。 SELECT CONSTRAINT_NAME = name, FOREIGN_SCHEMA = OBJECT_SCHEMA_NAME(parent_object_id), FOREIGN_TABLE = OBJECT_NAME(parent_object_id), …
3
クラスター化された列ストアインデックスと外部キー
インデックスを使用してデータウェアハウスのパフォーマンスをチューニングしています。私はSQL Server 2014を初めて使用します。Microsoftは次のように説明しています。 「クラスター化された列ストアインデックスは、大規模なデータウェアハウジングファクトテーブルを格納するための標準であり、ほとんどのデータウェアハウジングシナリオで使用されることを期待しています。操作を削除します。」 http://msdn.microsoft.com/en-us/library/gg492088.aspx ただし、ドキュメントをさらに読むと、制限と制限があります。 「一意の制約、主キーの制約、または外部キーの制約を持つことはできません。」 これは私をとても混乱させます！さまざまな理由（データの整合性、セマンティックレイヤーに表示される関係など）のために、データウェアハウスに外部キーを配置することをお勧めします（必須ではありません）。 そのため、Microsoftはデータウェアハウスシナリオのクラスター化列ストアインデックスを推奨しています。ただし、外部キー関係を処理できませんか？！ これは正しいですか？他にどのアプローチをお勧めしますか？過去には、データウェアハウスのシナリオで、クラスター化されていない列ストアインデックスを使用して、データロードのドロップと再構築を行いました。しかし、SQL Server 2014はデータウェアハウスに新しい価値を追加しませんか？
2
多対多および弱いエンティティ
別のエンティティに定義されない限り存在できないエンティティがあり、このエンティティを多対多の関係に参加させたい。 例：アーティストにはアルバムがあり（アルバムはアーティストなしでは存在できません）、アルバムにも多くのトラックがありますが、同じトラックが多くのアルバムに存在する可能性があります。 そのため、アルバムとトラックの間には多対多の関係があります。 アルバムが弱いエンティティである場合、その主キーはアーティストを参照する外部キーであるため、多対多の関係を表す別のテーブルへの外部キーにすることはできません。 問題は、SQLでこのような関係を持つことは可能ですか？その場合、どのように表現するのですか？
1
pg_restore.exeを使用する前に制約を無効にします
pg_restore.exeデータベースからダンプファイルを実行しようとすると、同じように何十ものエラーがスローされます。 ERROR: insert or update on table "someTable" violates foreign key constraint "aConstraintName" これは、データベースをダンプファイル（このファイルは運用データベースから取得）から復元する前に空にしたという事実によるものです。 ... を呼び出す前に、すべてのテーブルの制約とすべての外部キーを無効にし、pg_restore.exeその後、制約と外部キーを再度有効にする方法はありますか。 SOで何か面白いものを見つけました。制約チェックをコミット時間まで延期します。しかし、制約を延期した後にpg_restore.exe内部から呼び出すことはできないと思いpsql.exeます。 また、10年前のこの投稿もあり、制約を削除してから再度追加することを提案しています。または、pg_class reltriggersの値を0に変更すると、制約に対しても可能になります...しかし、それは良い習慣よりもハッキングされているのではないかと思います... この場合のベストプラクティスは何ですか？フラグを使用pg_dump.exe して-clean使用すると、データベースを復元するときに制約チェックをバイパスするダンプが作成されますか？
4
再帰的自己結合
私はcommentsこれを単純化できるテーブルを持っています： comments ======= id user_id text parent_id where parent_idはnull入力可能ですが、親コメントのキーになる場合があります。 さて、select特定のコメントのすべての子孫はどうすればいいですか？ コメントはいくつかのレベル下にあるかもしれません...
2
リレーショナルデータベースのルックアップテーブルに関するベストプラクティスは何ですか？
ルックアップテーブル（またはコードテーブルと呼ばれることもあります）は、通常、特定の列に指定できる値のコレクションです。 たとえば、次のparty2つの列を持つ（政党に関する情報を保存するための）というルックアップテーブルがあるとします。 party_code_idn、システム生成の数値を保持し、（ビジネスドメインの意味を欠いて）実際のキーの代理として機能します。 party_codeは、ビジネスドメインの意味を持つ値を保持するため、テーブルの実際のキーまたは「自然な」キーです。 そして、そのようなテーブルは以下のデータを保持しているとしましょう： +----------------+------------+ | party_code_idn | party_code | +----------------+------------+ | 1 | Republican | | 2 | Democratic | +----------------+------------+ party_code値は「共和党」と「民主党」を続けるの列は、テーブルの実際のキーであること、UNIQUE制約に設定されているが、私は必要に応じて添加party_code_idnし、論理的に言えば、ものの（表のPKとしてそれを定義しました、party_codeプライマリキー[PK]として機能する場合があります）。 質問 トランザクションテーブルからルックアップ値を指すためのベストプラクティスは何ですか？FOREIGN KEY（FK）参照を確立する必要があります（a）自然で意味のある値を直接参照するか、（b）値を代理しますか？ オプション（a）、たとえば +---------------+------------+---------+ | candidate_idn | party_code | city | +---------------+------------+---------+ | 1 | Democratic | Alaska | | 2 | Republican | Memphis …
2
条件付き外部キーの関係
現在、2つのエンティティ間に外部キーがあり、その関係をテーブルの1つのentityTypeを条件とするようにします。これがテーブルの階層です。これは、子から親へのFK参照を介して行われます Store / \ Employees \ TransactionalStores / | \ Kiosks | BrickMortars Onlines 現在、従業員から店舗へのFK関係があります ALTER TABLE Employees ADD CONSTRAINT Employee_Store FOREIGN KEY (TransStoreId) REFERENCES TransactionalStores(StoreId) 条件を追加したい： WHERE TransactionalStores.storeType != 'ONLINE_TYPE' これは可能ですか、またはTransactionalStoresを2つの新しいsubType（PhysicalStoresおよびVirtualStoresなど）にサブクラス化する必要がありますか
3
外部キー-代理キーまたは自然キーを使用してリンクしますか？
テーブル間の外部キーを自然キーまたはサロゲートキーにリンクするかどうかのベストプラクティスはありますか？私が本当に見つけた唯一の議論は（私のgoogle-fuが欠けていない限り）この質問でのJack Douglasの答えです。私はルールが変わるということを超えた議論を知っていますが、これはどんな状況でも考慮する必要があるものです。 尋ねる主な理由は、自然キーを持つFKを使用するレガシーアプリケーションがあることですが、開発者からOR / M（この場合はNHibernate）に移行する強いプッシュがあり、フォークは既にいくつかを生成していることです変更を壊すので、自然キーを使用して変更を元に戻すか、FKのサロゲートキーを使用するようにレガシーアプリを移動します。私の腸は元のFKを復元すると言っていますが、これが本当に正しい道かどうかは正直わかりません。 テーブルの大部分には、既に一意キーとPKが定義された代理キーと自然キーの両方が既に定義されているため、このインスタンスでは余分な列を追加する必要はありません。SQL Server 2008を使用していますが、これがすべてのDBに十分な汎用性を持っていることを願っています。
2
外部キーの削除に時間がかかるのはなぜですか？
次のように、一度に1つずつ、データベースからすべての外部キーを削除するスクリプトを作成しました。 ALTER TABLE MyTable1 DROP CONSTRAINT FK_MyTable1_col1 ALTER TABLE MyTable2 DROP CONSTRAINT FK_MyTable2_col1 ALTER TABLE MyTable2 DROP CONSTRAINT FK_MyTable2_col2 私が驚いたのは、スクリプトに時間がかかることです。DROPFKごとに平均20秒です。今、私はFKを作成することは大したことかもしれないことを理解しています、なぜならサーバーはFK制約が最初から侵害されていないことを確認しなければならないからです？時間がかかるFKをドロップするとき、サーバーは何をしますか？これは私自身の好奇心のためであり、物事をより速くする方法があるかどうかを理解するためです。FKを（単に無効にするだけでなく）削除できると、移行中にはるかに高速になり、したがってダウンタイムを最小限に抑えることができます。
5
大きなアプリケーションのために、同じデータベースの異なるスキーマのテーブルに外部キーを作成するのは悪い考えですか？
私は大きなpl / sql Webベースのアプリケーションを専用サーバーに転送する作業をしています。このアプリケーションは、プログラムコードの70パッケージを含む1つのスキーマにあります。このアプリケーションは、さまざまな時期に約15人で作成されました。また、異なるスキーマの参照テーブルに外部キーを作成することは通常の習慣でした。異なるスキーマに同じ参照テーブルを保持する必要がないため、本当に便利でデータベースを非常にクリーンに保つためです。 しかし、とにかく私のDBA（DBを使用して新しいインスタンスを作成し、Solarisゾーン内にアプリケーションをコピーした）は、今日、「異なるスキーマの外部キーは悪で、破壊する必要があります！」彼は自分の見解を説明しなかった。 大きなアプリケーションでそれを行うのは本当に悪い考えですか？
2
MySQL-それ自体を参照する外部キー制約を持つ行を削除します
ユーザーが私のウェブサイトに投稿したすべてのフォーラムメッセージを保存するテーブルがあります。メッセージ階層構造は、入れ子集合モデルを使用して実装されます。 以下は、テーブルの単純化された構造です。 Id（主キー） Owner_Id（IDへの外部キー参照） Parent_Id（IDへの外部キー参照） nleft そろそろ nlevel これで、テーブルは次のようになります。 + ------- + ------------- + -------------- + ---------- + ----------- + ----------- + | Id | Owner_Id | Parent_Id | nleft | nright | nlevel | + ------- + ------------- + -------------- + ---------- + ----------- + ----------- + | 1 …
2
PostgreSQL-挿入/更新が外部キー制約に違反しています
私はpostgreSQLの新人です。3つのテーブルがあり、1つのテーブルが他の2つのテーブルの主キーを参照しています。しかし、データをに挿入できませんでしたTable3。以下のコードを参照してください： DROP TABLE Table1 CASCADE; CREATE TABLE Table1( "DataID" bigint NOT NULL DEFAULT '0', "AdData" integer DEFAULT NULL, PRIMARY KEY ("DataID") ); DROP TABLE IF EXISTS Table2 CASCADE; CREATE TABLE Table2 ( "Address" numeric(20) NOT NULL DEFAULT '0', "Value" numeric(20) DEFAULT NULL, PRIMARY KEY ("Address") ); DROP TABLE IF EXISTS …
3
「WITH NOCHECK」を使用して外部キーを作成すると、何が失われますか？
EXISTS()FKルックアップ値で呼び出しを行うと、そのFK制約が信頼できる場合、結果はすぐにわかります。 そして、それが信頼されていない場合（を使用してFKを作成するときなどWITH NOCHECK）、SQL Serverはテーブルに移動して、値が実際に存在するかどうかを確認する必要があります。 他に使用することで失うものはありNOCHECKますか？
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.