आपको निश्चित रूप से . करना चाहिए एक सरोगेट पेश करें INT IDENTITY() प्राथमिक कुंजी !!INT पहले से ही आपको संभावित रूप से 2 अरब पंक्तियों तक देता है - क्या यह पर्याप्त नहीं है ??
SQL सर्वर पर यह प्राथमिक कुंजी/क्लस्टर कुंजी आकार में 64 बाइट्स (4 के बजाय, एक INT के लिए) तक होगी - जो आपके क्लस्टर इंडेक्स और आपके सभी गैर-क्लस्टर इंडेक्स को मान्यता से परे फूलाएगी। संपूर्ण क्लस्टरिंग कुंजी (आपके सभी 8 कॉलम) उस टेबल पर प्रत्येक गैर-क्लस्टर इंडेक्स के प्रत्येक पृष्ठ पर शामिल की जाएंगी - निश्चित रूप से बहुत सारी जगह और बहुत सारी जगह बर्बाद कर रही है।
तो किसी भी इंडेक्स टेबल पर, आपके पास सरोगेट आईएनटी क्लस्टर कुंजी के साथ 16 गुना अधिक प्रविष्टियां होंगी - इसका मतलब है कि बहुत कम I/O, बहुत कम समय बर्बाद इंडेक्स पेज पढ़ने में।
और कल्पना करें कि उस तालिका के साथ एक विदेशी-कुंजी संबंध स्थापित करने की कोशिश कर रहा है .... किसी भी चाइल्ड टेबल में सभी 8 कॉलम होने चाहिए। अपनी प्राथमिक कुंजी को विदेशी कुंजी कॉलम के रूप में, और प्रत्येक जॉइन में सभी 8 कॉलम निर्दिष्ट करें - क्या बुरा सपना है !!
78 मिलियन पंक्तियों में, यहां तक कि केवल क्लस्टरिंग कुंजी को INT पहचान में बदलने से आप प्रति पंक्ति 60 बाइट्स तक बचा सकते हैं - यह अकेले 4 GByte डिस्क स्थान (और आपके सर्वर में RAM उपयोग) तक आ जाएगा। और वह गैर-संकुल सूचकांकों पर बचत की गणना करना भी शुरू नहीं कर रहा है.......
और हां, मैं VARCHAR(10) को INT या BIGINT में भी बदलूंगा - यदि यह एक संख्या है, तो फ़ील्ड प्रकार को संख्यात्मक बनाएं - इसे वास्तव में VARCHAR(10) पर छोड़ने का कोई मतलब नहीं है। लेकिन वह अकेले गति या प्रदर्शन के मामले में बहुत बड़ा अंतर नहीं लाने वाला है - यह केवल डेटा के साथ काम करना इतना आसान बनाता है (उदाहरण के लिए मूल्यों की तुलना करते समय हमेशा संख्यात्मक प्रकारों को डालने की आवश्यकता नहीं होती है)।
मार्क
