2012-10-02 14 views
6

Heredé una base de datos de SQL Server que tiene una tabla con una clave principal llamada RecordID. La definición de la tabla y la clave externa se define así:Por qué crear una restricción de clave externa que hace referencia a la clave primaria de la misma tabla desde el campo de clave principal

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 

Podría entender esto si la clave externa hace referencia a un campo diferente en la misma mesa de vuelta al campo de clave primaray lo que permitiría una jerarquía, pero en En este caso, los dos campos en la definición de clave externa son exactamente el mismo campo. ¿Es solo un error en la definición original de la tabla y la clave externa? ¿O hay una ventaja real de alguna manera para esto?

Gracias de antemano por su tiempo en responder.

+0

Quizás compruebe si hay otra tabla en la base de datos que parece que * debería * estar haciendo referencia a esta tabla, pero no lo está. –

Respuesta

4

Como la clave externa hace referencia a sí misma, la comprobación nunca puede fallar. Eso lo hace, como una restricción, un no-op, por lo que es en todos los sentidos de la palabra, extraños. Alguien claramente cometió un error al crear la restricción.

Pensé que me estaba perdiendo algo, así que una comprobación rápida apareció con esto: http://www.dotnetnuke.com/Resources/Forums/forumid/-1/postid/342163/scope/posts.aspx que refuerza mi sospecha (error de usuario). Mi conclusión más culta es que alguien en algún momento pensó en crear una restricción de tabla autorreferencial (otra columna), pero en un retorcido giro de confusión creó esta abominación.

Cuestiones relacionadas