एंटिटी फ्रेमवर्क सभी विदेशी कुंजी स्तंभों को अनुक्रमित करता है

ईएफ कोड फर्स्ट में, आप एक विदेशी कुंजी संबंध का मॉडल बनाने का सामान्य कारण संस्थाओं के बीच नौगम्यता के लिए है। Country . के एक साधारण परिदृश्य पर विचार करें और City , निम्नलिखित LINQ कथन के लिए परिभाषित उत्सुक लोडिंग के साथ:

var someQuery = 
   db.Countries
     .Include(co => co.City)
     .Where(co => co.Name == "Japan")
     .Select(...);

इसके परिणामस्वरूप निम्नलिखित की तर्ज पर एक प्रश्न होगा:

SELECT *
FROM Country co
INNER JOIN City ci
  ON ci.CountryId = co.ID
WHERE co.Name = 'Japan';

City.CountryId . पर विदेशी कुंजी पर इंडेक्स के बिना , SQL को जॉइन के दौरान देश के शहरों को फ़िल्टर करने के लिए शहरों की तालिका को स्कैन करने की आवश्यकता होगी।

FK इंडेक्स में प्रदर्शन लाभ भी होंगे यदि पंक्तियों को हटा दिया जाता है मूल देश तालिका से, संदर्भात्मक अखंडता के रूप में किसी भी लिंक की गई शहर पंक्तियों की उपस्थिति का पता लगाने की आवश्यकता होगी (चाहे FK में ON CASCADE DELETE हो) परिभाषित है या नहीं)।

TL;DR

विदेशी कुंजियों पर अनुक्रमणिका हैं अनुशंसित , भले ही आप सीधे विदेशी कुंजी पर फ़िल्टर न करें, फिर भी जॉइन में इसकी आवश्यकता होगी। इसके अपवाद काफी काल्पनिक प्रतीत होते हैं:

• यदि विदेशी कुंजी की चयनात्मकता बहुत कम है, उदा। उपरोक्त परिदृश्य में, यदि देशों की तालिका में सभी शहरों का 50% जापान में था, तो सूचकांक उपयोगी नहीं होगा।

• यदि आप वास्तव में कभी भी रिश्ते में नेविगेट नहीं करते हैं।

• अगर आप पैरेंट टेबल से पंक्तियों को कभी नहीं हटाते हैं (या PK पर अपडेट करने का प्रयास करते हैं)।

एक अतिरिक्त अनुकूलन विचार यह है कि Clustered Index . में विदेशी कुंजी का उपयोग करना है या नहीं चाइल्ड टेबल (यानी देश के अनुसार क्लस्टर सिटीज)। यह अक्सर माता-पिता में फायदेमंद होता है:बाल तालिका संबंध जहां माता-पिता के लिए सभी बाल पंक्तियों को एक साथ पुनर्प्राप्त करना आम जगह है।