プライマリキーフィールドから同じテーブルのプライマリキーを参照する外部キー制約を作成する理由

Question

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 

は、私が理解することができ、この場合、バック階層構造を可能にするprimarayキーフィールドに同じテーブル内の別のフィールドから参照する外部キーが、中この場合、外部キー定義内の2つのフィールドはまったく同じフィールドです。これは、テーブルと外部キーの元の定義ではちょうど間違いですか？それとも何とかこれに本当の利点がありますか？

返信いただきありがとうございます。

Answer 1

外部キーが自身を参照するため、チェックは失敗しません。それは、制約として、それはノーオペレーションなので、それは単語のすべての意味でです。外的。誰かが明らかに制約を作成するのに間違いを犯しました。

私は何かが不足している可能性があると思っていましたので、素早くチェックしました：http://www.dotnetnuke.com/Resources/Forums/forumid/-1/postid/342163/scope/posts.aspx私の疑惑（ユーザーエラー）を補強します。私の最も教育された結論は、ある段階の誰かが自己参照（他の列）テーブル制約を作成することを考えたが、混乱の邪悪な歪曲でこの嫌悪を作り出したということです。