2010-10-11 9 views
16

मैं भी अक्सर "नहीं अशक्त प्राथमिक कुंजी" ब्लॉग, लेख, पुस्तकें, मंचों में TSQL में तालिका बनाने, अतः यहाँ लिपियों में, आदिटीएसक्यूएल में "नल प्राथमिक कुंजी" का उपयोग क्यों करें?

उदाहरण के लिए देख रहा हूँ, बिंग देता 630,000 परिणाम ((सिर्फ अंग्रेजी में) "रिक्त नहीं" के पास "प्राथमिक कुंजी" "एसक्यूएल सर्वर के विरुद्ध खोज करने के लिए करता है, तो":
http://www.bing.com/search?q=%22not+null%22+NEAR+%22primary+key%22+%22sql+server%22&go=&form=QBRE&filt=lf

मैं हमेशा कथित "। नहीं nULL" प्राथमिक कुंजी, कम से कम एसक्यूएल सर्वर में की परिभाषा के अभिन्न अंग के रूप में
मैंने SQL सर्वर में "नॉट नहीं" के साथ और बिना प्राथमिक कुंजी के साथ एक टेबल बनाने की कोशिश की लेकिन संभव अंतर को समझ नहीं पाया।

तेजी से (संक्षिप्त) चित्रों में भी प्राथमिक कुंजी बनाने के लिए सभी "नॉट नल" का उपयोग क्यों करते हैं?


अद्यतन:
कुछ भी पहचान या अद्वितीय होना (और साथ ही कई NULLs रोकने अगर एक की अनुमति दी है) कैसे नल कर सकते हैं? यह अनिर्दिष्ट, लापता, नहीं लागू मूल्य

मेरा प्रश्न भी निहित subquestions है:
अगर एक पी के लिए परिभाषित करता है "शून्य नहीं", क्यों तो अद्वितीय निर्दिष्ट नहीं है?
और पीके की परिभाषा क्या है। क्या यह अद्वितीय कन्स्ट्रेंट + न्यूल या अद्वितीय इंडेक्स नहीं है (फिर क्यों न्यूल नहीं)?
Plz मुझे एमएसडीएन दस्तावेज़ों पर लिंक दें।

Update2: @Damien_The_Unbeliever

क्यों बिना "नहीं NULL" पर्याय नहीं है?


  • Microsoft SQL सर्वर प्रबंधन स्टूडियो


    कोई पंक्ति अद्यतन किया गया था:

    CREATE TABLE T3 
    (
        PK int -- NOT NULL commented out 
        , nonPK int -- to double-check my sanity 
        , constraint PK_vgv8 PRIMARY KEY (PK) on [PRIMARY] 
    ) 
    

    अभी भी शून्य देने की अनुमति नहीं देता।

    पंक्ति 2 में डेटा प्रतिबद्ध नहीं था। त्रुटि स्रोत: .NET SqlClient डेटा प्रदाता। त्रुटि संदेश: कॉल 'पीके', तालिका 'TestData.dbo.T3' में मान NULL सम्मिलित नहीं कर सकता; कॉलम नल की अनुमति नहीं देता है। INSERT विफल रहता है।

    कथन समाप्त कर दिया गया है।

    त्रुटियों को ठीक करें और परिवर्तन को रद्द करने के लिए पुनः प्रयास करें या ESC दबाएं।


    ठीक सहायता


Update3:
यह, अवधारणाओं और शर्तों परिभाषा, के रूप में अव्यावहारिक उपद्रव प्रकट हो सकता है।
यह नहीं है, कुछ गलत कथन (संचार/चर्चा के दौरान अन्य (दूसरों) की राय में) एक मूल धारणा पर एक मूर्खता माना जाता है और पेशेवर बातचीत और संचार में बाधाओं को बनाने के लिए पर्याप्त है।

मैं यह बताना भूल गया कि पीके के लिए एसएसएमएस द्वारा पूरी तरह से लिखित नहीं है!

+0

यदि आपको विशिष्ट रूप से पहचाना जा सकता है तो आपको रिकॉर्ड कैसे मिलेगा ????? – leppie

+0

@InSane, मैं GOOGLE से काफी आदी था लेकिन बीएनजी उन परिणामों को ढूंढने के लिए हुआ जो GOOGLE नहीं करते हैं (विशेष रूप से हटाए गए वेबपृष्ठों के लिए कैश)। इसके अलावा, google.com google.ru पर रीडायरेक्ट करता है जब मैं केवल अंग्रेजी में खोज करता हूं तो मुझे सिरिलिक (रूसी) में बहुत सारे परिणाम देते हैं। –

+1

@leppie, मुझे समझ में नहीं आया, "पीके = अद्वितीय + नहीं NuLL" SQL सर्वर (?) में, कृपया अपना उत्तर –

उत्तर

14

संपादित स्पष्टता

के लिए एसक्यूएल विशिष्टता के अनुसार, एक प्राथमिक कुंजी शून्य नहीं हो सकते। इसका मतलब यह है कि "न कि प्राथमिक प्राथमिक कुंजी" या सिर्फ "प्राथमिक कुंजी" के साथ एक स्तंभ को सजाने के लिए एक ही काम करना चाहिए। लेकिन आप SQL मानक पर SQL मानक के बाद सही ढंग से प्रश्न में भरोसा कर रहे हैं। प्रारंभिक बग के कारण एक उदाहरण के रूप में, एसक्यूएल लाइट मानक को सही ढंग से कार्यान्वित नहीं करता है और गैर-पूर्णांक प्राथमिक कुंजी में शून्य मानों को अनुमति देता है (sqlite.org/lang_createtable.html देखें)। इसका मतलब होगा (कम से कम) SQLLite दो बयान दो अलग-अलग चीजें करते हैं।

"पूर्ण प्राथमिक कुंजी" स्पष्ट रूप से इरादे को इंगित करता है और प्राथमिक कुंजी को हटाए जाने पर भी गैर-शून्य मानों को जारी रखता है, यह पसंदीदा वाक्यविन्यास होना चाहिए।

+0

मैंने पीके के बिना पीके के बारे में पूछा "बिना नहीं, पीके के बिना" नॉट "नहीं। मैं किसी भी संभावित तरीके से पीके क्षेत्र में न्यूल का प्रबंधन नहीं कर सका। –

+0

@ vgv8: भ्रम के लिए खेद है, स्पष्ट होने के लिए मैं कह रहा था आपके पास "प्राथमिक कुंजी" या "पूर्ण प्राथमिक कुंजी नहीं" हो सकती है और वे दोनों एक ही काम करेंगे। लेकिन अगर आपने "प्राथमिक कुंजी" को हटा दिया है, तो पहला कथन तब कॉलम को नल की अनुमति देने की अनुमति देगा, जबकि दूसरा होगा 't, अन्य शब्दों में, केवल दूसरा वांछित इरादे का वर्णन करता है, जबकि पहला स्निटेक्स शॉर्ट कट का लाभ ले रहा है। मुझे यकीन है कि वे नहीं करेंगे, लेकिन अगर एमएस ने प्राथमिक कुंजी में एक नल को अनुमति देने के लिए एसक्यूएल बदल दिया तो दो व्यवहार मूल रूप से अलग होंगे। –

+0

मैं औपचारिकताओं को छोड़ने का प्रस्ताव करता हूं। जैसे @ पॉल हैडफील्ड, अगर कोई और चर्चा में भाग नहीं ले रहा है। मैंने टिप्पणी में दिए गए लिंक के लिए अपना उत्तर अधिक बढ़ाया, अंतर्दृष्टि के लिए सहायक और कुछ परिभाषाओं या दृष्टिकोणों को प्रकट किया, मुख्य ए के मुकाबले खुद को झुकाओ। मैंने subquestion http://stackoverflow.com/questions/3906811/why-to-permit-null-in-primary-key भी पोस्ट किया। मौलिक अवधारणाएं और सिद्धांत हैं, जो मेरा मानना ​​है कि आम होना चाहिए, और विभिन्न आरडीबीएमएस –

1

यह वाक्य रचनात्मक रूप से आवश्यक नहीं है क्योंकि यह अन्य कॉलम के लिए डिफ़ॉल्ट सेटिंग के बावजूद प्राथमिक कुंजी कॉलम के लिए निर्दिष्ट नहीं है, तो यह डिफ़ॉल्ट होगा।

SET ANSI_NULL_DFLT_ON ON /*Set default for columns to allow NULL if not specified*/ 

CREATE TABLE #t 
(
i INT PRIMARY KEY, 
j INT 
) 

SELECT name,is_nullable 
FROM tempdb.sys.columns 
WHERE object_id=object_id('tempdb..#t') 


INSERT INTO #t VALUES (1,NULL) /*Succeeds as j allows NULL*/ 

INSERT INTO #t VALUES (NULL, 1)/*Won't succeed as column doesn't allow nulls*/ 

DROP TABLE #t 
+1

+1 पर एक शानदार से बनाने से बचाया। पोस्ट करने से पहले मैंने वास्तव में ऐसी स्क्रिप्ट चलाई। फिर भी मैं स्पष्ट परिभाषाएं और जवाब क्यों लेना चाहता हूं। यह मौलिक अवधारणा है और मैं –

0

सभी प्राथमिक कुंजी का मतलब है कि यह तालिका के लिए पहचानकर्ता है और परिभाषा के अनुसार अद्वितीय है। अनोखा मतलब शून्य नहीं है, इसलिए यदि आपके पास आवश्यकता है कि प्राथमिक कुंजी शून्य नहीं हो सकती है तो आपको स्पष्ट रूप से निर्दिष्ट करना होगा। यदि आप शून्य की अनुमति देते हैं तो आप केवल यह कह रहे हैं कि कॉलम में शून्य मान होना ठीक है, लेकिन आपको केवल एक होने की अनुमति है क्योंकि इसे अद्वितीय होना चाहिए।

+0

को ऐसे साधारण बुनियादी प्रश्नों का उत्तर देते समय मुझे क्लाउन से नहीं बनाना चाहता हूं, आपको इसे स्पष्ट रूप से निर्दिष्ट करने की आवश्यकता नहीं है। यह पीके बनाकर निहित है। –

8

निम्नलिखित:

CREATE TABLE T1 (
    T1ID int not null, 
    constraint <system generated name> PRIMARY KEY (T1ID) on [PRIMARY] 
) 

स्तंभ परिभाषा वास्तव में बाधा परिभाषा से काफी अलग है:

CREATE TABLE T1 (
    T1ID int not null primary key 
) 

वास्तव में निम्नलिखित के लिए आशुलिपि है। यह सिर्फ इतना है कि शॉर्टेंड इस तथ्य को छुपाता है कि यह दो अलग-अलग परिभाषाएं हैं। (बेशक, यदि आप लंबे हाथ के फॉर्म का उपयोग करते हैं, तो आप कई कॉलम में प्राथमिक कुंजी को परिभाषित करने जैसी चीजें कर सकते हैं)।

अद्यतन के जवाब में संपादित करें। नहीं, आपके पास अभी भी प्राथमिक कुंजी में एक शून्य कॉलम नहीं हो सकता है। लेकिन यह देखते हुए कि एक तालिका तालिका कथन में प्रत्येक कॉलम की शून्यता निर्दिष्ट करना सामान्य है, यह केवल इसे छोड़ने के लिए अजीब लगता है (भले ही यह प्राथमिक कुंजी बाधा द्वारा निहित/आवश्यक है)।

CREATE TABLE T1 (
    T1ID int, 
    constraint <system generated name> PRIMARY KEY (T1ID) on [PRIMARY] 
) 

पिछले कोड नमूना के समान बिल्कुल तालिका बनाता है। एक कॉलम की "शून्य नहीं" की स्पष्टता को स्पष्ट रूप से निर्दिष्ट करना, आवश्यकता के बजाए परिणाम की एक स्पष्ट स्वीकृति है।

और अंत में, आप इसे अक्सर उदाहरण कोड में पाएंगे क्योंकि लोगों ने अपना डेटाबेस विकसित किया है, और फिर अपने डेटाबेस से एक स्क्रिप्ट उत्पन्न करने के लिए SQL टूल में निर्मित किया गया है - स्क्रिप्टिंग टूल हमेशा सब कुछ स्पष्ट रूप से डालते हैं।

+1

मैंने नहीं पूछा कि मैं कर सकता हूं या नहीं। मैंने पूछा कि एसएसएमएस द्वारा "प्राथमिक कुंजी" टीएसक्यूएल परिभाषा के अतिरिक्त "नॉट न्यूल" क्यों लिखित है –

2

मुझे किसी भी डीबीएमएस के बारे में पता नहीं है जो प्राथमिक कुंजी बाधा में उपयोग किए जाने वाले एक शून्य कॉलम को अनुमति देता है। एसक्यूएल मानक निर्दिष्ट करता है कि प्राथमिक कुंजी बाधा में कॉलम शून्य नहीं हो सकते हैं।

संबंधपरक मॉडल उम्मीदवार कुंजी में अद्वितीय मान होते हैं, नल नहीं। यह एसक्यूएल की एक विशिष्टता है कि निरर्थक कॉलम वैकल्पिक रूप से अद्वितीय बाधाओं में उपयोग किया जा सकता है। यह सुविधा शायद डेटा की कई समस्याओं के लिए ज़िम्मेदार है। मैं अत्यधिक अनुशंसा करता हूं कि आप अद्वितीय बाधाओं में निरर्थक कॉलम का उपयोग करने से बचें। यदि आवश्यक हो, तो गैर-शून्य मानों के लिए एक नई तालिका बनाएं और उस पर अद्वितीय बाधा डालें।

1

MYSQL के बारे में मजाकिया बात यह है कि जब आप primary key auto_increment फ़ील्ड में एक न्यूल (या 0) मान पास करते हैं तो व्यवहार बहुत अच्छा होता है।

आप

create table Users(

    userId int primary key auto_increment 

) ; 

insert into users(userId) values (null) ; -- insert OK 
select * from Users ; -- Shows 1 

है इसलिए यदि आप एक auto_increment क्षेत्र के लिए 0 या शून्य से पारित, यह सिर्फ अगले उपलब्ध मूल्य का चयन करता है कहो।

यदि आप के साथ NULL विफल रहता है प्राथमिक कुंजी क्षेत्र में बंद auto_increment संपत्ति, एक डालने लेते हैं, क्योंकि प्राथमिक कुंजी नल नहीं हो सकता, त्रुटि है। तो NOT NULLPRIMARY KEY NOT NULL पर कम से कम MySQL में अंतर्निहित है।

0

मुझे लगता है कि एक प्राथमिक क्षेत्र में शून्य और प्राथमिक कुंजी को तब भी स्वीकार नहीं किया जाता है जब प्राथमिक कुंजी स्वयं स्पष्ट रूप से शून्य नहीं होती है।

हमें बताएं कि हमारे पास टेबल तालिका 1 है जिसका अर्थ है कि यह 2 आयामी डेटा स्टोर करने के लिए अपना मूल्य रखेगा। यदि मैं केवल एक फ़ील्ड के साथ एक टेबल बनाता हूं तो यह स्वीकार्य है, लेकिन वास्तविक वस्तु दुनिया में इसका वास्तविक समय उपयोग क्या है? यह एक आयामी तालिका होगी जो सिर्फ एक फ़ील्ड के डेटा को संग्रहीत करेगी, कोई जानकारी नहीं, मुझे विश्वास है। और उस क्षेत्र को शून्य मानों को स्वीकार करने के लिए अर्थहीन है।

अब, मान लीजिए, हमने एक टेबल को 2 फ़ील्ड के साथ परिभाषित किया है जिसका अर्थ है कि उचित डेटा से भरने पर हम प्रत्येक पंक्ति से अच्छी जानकारी खींच सकते हैं।

नल मूल्य स्वीकार करने वाले उन 2 फ़ील्ड को किसी भी भाव की उम्मीद नहीं है अगर हम कचरा धक्का देना चाहते हैं या गिनती (*) की अपेक्षा अतिरिक्त पंक्ति में होना चाहिए।

तो, मेरा कहना है कि, अगर हम सामान्य मौलिक आरडीबीएमएस अवधारणाओं के साथ सामान्यीकृत टेबल का उपयोग करना चाहते हैं तो कम से कम 2 फिल्में के लिए अनिवार्य नहीं है। यह सोचने से पहले कि तालिका को प्राथमिक कुंजी को बाधा के रूप में चाहिए, हम हमेशा शून्य के साथ दायर टीएच को परिभाषित करते हैं। और यदि आवश्यक हो तो प्राथमिक कुंजी का उपयोग करें और ध्यान दें कि आप इसे किसी भी समय छोड़ सकते हैं लेकिन 'शून्य नहीं'

और यदि हमें यकीन है कि हम प्राथमिक कुंजी नहीं छोड़ेंगे, केवल प्राथमिक कुंजी का उपयोग करें, अन्यथा शून्य न करें और प्राथमिक कुंजी।

यह सब उपयोग पर निर्भर करता है और जैसा कि मैंने कहा है, मूल तालिका परिभाषाएं और अच्छे डीबी प्राप्त करने के लिए कोडड नियम प्राप्त किया जाना चाहिए।

संबंधित मुद्दे