0

と呼ばれる主キーを持つデータテーブルがありますOptDefID。このテーブルのレコードが削除されたら、フィールド（in ）にPermissionsそのレコードがあるテーブルからすべてのレコードを削除する必要があります。私にとってトリッキーな部分は、テーブルに主キーがなく、さまざまな種類のアクセス許可を保持し、フィールドがあることです。ANDが。の行を削除する必要があります。OptDefIDdefIDPermissionsPermissionspermissiontypeOptDefIDpermissiontypeOptDef

パーミッションタイプを考慮する必要があるため、ここでは外部キー制約が適切であるとは思いません（またはそうですか？）。

トリガーの作成も検討しましたが、OptDefIDをトリガーに渡す方法がわかりません。

これはアプリケーション自体を介して行うことができますが、これはデータベースレベルのソリューションである必要があると思います。

最善の解決策は何ですか？

4

3 に答える 3

0

問題のレコードがテーブルを参照している場合OptDefIdにのみ列が入力される場合はPermissions、外部キーが適切である必要があります。つまり、別の列MemberIdがあり、それがテーブルの外部キーである可能性がありMembersます。

外部キーを使用できないObjectIdのは、列の内容が変化するにつれて他の意味を持つ単一の列（それを呼びましょう）がある場合のみです。typeその場合、すでにお察しのとおり、トリガーがおそらく最善のアプローチです。Oracle PL / SQLのトリガーについてのみ知っています。トリガーは、新旧の状態を表す個別の完全な行として渡されます。MS-SQL-Serverでも同様だと思います。

于 2012-11-12T14:44:50.553 に答える
0

defID が 20 で、permissiontype が「OptDef」の Permissions から削除したいとします。Permissions には、defID が 20 で、permissiontype が「Member」の別の行がある場合があります。この番組は、Opt データではなくメンバーに関連するため、削除しないでください。

あなたが発見したように、テーブル名をフィールドに格納すると、外部キーが適切に機能しなくなります。

根本的な問題を解決し、これら 2 つの外部キーを分離して、それぞれを個別に適用できるようにすることをお勧めします。例えば：

CREATE TABLE Permissions (
    ...
    OptDefId int,
    MemberId int,
    FOREIGN KEY (OptDefId) REFERENCES OptDef ON DELETE CASCADE,
    FOREIGN KEY (MemberId) REFERENCES Members ON DELETE CASCADE,
    CHECK (
        (OptDefId IS NOT NULL AND MemberId IS NULL)
        OR (OptDefId IS NULL AND MemberId IS NOT NULL)
    )
)

CHECK は、FK の 1 つのみが非 NULL であることを確認し、非 NULL FK のみが適用されるようにします。

または、現在の設計を変更せずにトリガーを介してこの「特別な」FK を強制することもできますが、可能な場合はトリガーよりも宣言型の制約を優先する必要があります。

于 2012-11-12T16:19:58.177 に答える
0

join with ステートメントを使用するだけでなく、 &ステートメントSELECTで複数のテーブルを結合することもできます。DELETEUPDATE

Permissions問題を理解しているので、テーブルをOptDefID列のあるテーブルに結合し、次のWHEREような句を追加できるはずです。

DELETE MyTable
...
WHERE [Permissions].permissiontype = 'OptDef'

また、これらのリンクも興味深い場合があります。

于 2012-11-12T14:50:30.257 に答える