6

RecordID という名前の主キーを持つテーブルを持つ SQL Server データベースを継承しました。次のように定義されたテーブル定義と外部キー:

CREATE TABLE [dbo].[MyTable](
  [RecordId] [int] IDENTITY(1,1) NOT NULL,
  [FileName] [nvarchar](255) NOT NULL,
  [Record] [nvarchar](255) NOT NULL,
  [ErrorDescription] [nvarchar](255) NULL,
  [ProcessDate] [datetime] NOT NULL,
 CONSTRAINT [PK_MyTable] PRIMARY KEY CLUSTERED 
(
  [RecordId] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON, FILLFACTOR = 90) ON [PRIMARY]
) ON [PRIMARY]

GO

ALTER TABLE [dbo].[MyTable]  WITH CHECK ADD  CONSTRAINT [FK_MyTable_MyTable] FOREIGN KEY([RecordId])
REFERENCES [dbo].[MyTable] ([RecordId])
GO

ALTER TABLE [dbo].[MyTable] CHECK CONSTRAINT [FK_MyTable_MyTable]
GO

外部キーが同じテーブルの別のフィールドから主キー フィールドに戻って参照され、階層構造が可能になる場合、これは理解できますが、この場合、外部キー定義の 2 つのフィールドはまったく同じフィールドです。これは、テーブルと外部キーの元の定義が間違っているだけですか? それとも、これにはどういうわけか本当の利点がありますか?

返信にお時間をいただきありがとうございます。

4

1 に答える 1

4

外部キーはそれ自体を参照するため、チェックが失敗することはありません。それは、制約として、それをノーオペレーションにするので、それは言葉のあらゆる意味で、無関係です。誰かが明らかに制約の作成を間違えました。

私は何かが足りないかもしれないと思ったので、これで簡単なチェックが見つかりました：http: //www.dotnetnuke.com/Resources/Forums/forumid/-1/postid/342163/scope/posts.aspxこれは私の疑いを補強します（ユーザーエラー）。私の最も知識のある結論は、ある段階で誰かが自己参照（他の列）テーブル制約を作成することを考えたが、混乱の邪悪なひねりでこの忌まわしさを作成したということです。

于 2012-10-02T05:32:27.327 に答える