प्राथमिक कुंजी फ़ील्ड

Question

से उसी तालिका की प्राथमिक कुंजी का संदर्भ देने वाली विदेशी कुंजी बाधा क्यों बनाएं I 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 कुंजी क्षेत्र है जो एक पदानुक्रम के लिए अनुमति होगी के लिए एक ही तालिका में एक अलग क्षेत्र से संदर्भित है, लेकिन में इस मामले में विदेशी कुंजी परिभाषा में दो फ़ील्ड बिल्कुल एक ही क्षेत्र हैं। क्या यह तालिका और विदेशी कुंजी की मूल परिभाषा में सिर्फ एक गलती है? या क्या इसका कोई वास्तविक लाभ है?

उत्तर देने में आपके समय के लिए अग्रिम धन्यवाद।

Answer 1

क्योंकि विदेशी कुंजी संदर्भ खुद ही है, चेक कभी विफल नहीं हो सकता है। यह इसे एक बाधा के रूप में बनाता है, एक नो-ऑप, इसलिए यह शब्द के हर भाव में है, बाह्य। किसी ने स्पष्ट रूप से बाधा उत्पन्न करने में गलती की।

मैंने सोचा कि मुझे कुछ याद आ रहा है, इसलिए एक त्वरित जांच इस के साथ चालू हुई: http://www.dotnetnuke.com/Resources/Forums/forumid/-1/postid/342163/scope/posts.aspx जो मेरे संदेह (उपयोगकर्ता त्रुटि) को मजबूत करता है। मेरा सबसे शिक्षित निष्कर्ष यह है कि किसी ने किसी चरण में आत्म-संदर्भ (अन्य कॉलम) तालिका की बाधा उत्पन्न करने के बारे में सोचा था, लेकिन भ्रम की एक दुष्ट मोड़ में इस घृणा उत्पन्न हुई।