Sql 为什么要创建从主键字段引用同一表的主键的外键约束

我继承了一个SQL Server数据库，该数据库有一个名为RecordID的主键表。表定义和外键定义如下：

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键字段（这将允许继承权），我可以理解这一点，但在这种情况下，外键定义中的两个字段是完全相同的字段。这只是表和外键的原始定义中的一个错误吗？或者这真的有好处吗

---

提前感谢您抽出时间回复。

因为外键引用自身，所以检查永远不会失败。这使得它，作为一个约束，是一个不可操作的，所以它在这个词的每一个意义上，都是无关的。显然有人在创建约束时犯了错误

---

我想我可能遗漏了什么，所以快速检查了一下：这加强了我的怀疑（用户错误）。我得到的最有教育意义的结论是，在某个阶段，有人曾想过创建一个自引用（其他列）表约束，但在一次混乱的扭曲中，创建了这个讨厌的约束。

也许可以检查数据库中是否有其他表看起来应该引用这个表，但实际上没有。