प्राथमिक कुंजी बनाम एमडी 5 हैश का उपयोग करने के पेशेवरों और विपक्ष एसक्यूएल सर्वर

Question

में प्राथमिक कुंजी के रूप में एक int पहचान का उपयोग करते हैं। मेरे पास फ़ाइल से निपटने के लिए एक एप्लिकेशन है और इसे कई सेगमेंट में विभाजित करने के लिए एक एप्लीकेशन है, फिर परिणाम को SQL सर्वर में सहेजें डेटाबेस। कई डुप्लिकेट फ़ाइल (शायद अलग-अलग फ़ाइल पथ के साथ) हैं, इसलिए पहले मैं इन सभी फ़ाइलों के माध्यम से जाता हूं और प्रत्येक फ़ाइल के लिए एमडी 5 हैश की गणना करता हूं, और [डुप्लिकेट] कॉलम का उपयोग करके डुप्लिकेट फ़ाइल को चिह्नित करता हूं।

फिर हर रोज, मैं इस एप्लिकेशन को चलाऊंगा और परिणामों को [परिणाम] तालिका में सहेज दूंगा। डाटाबेस स्कीमा के रूप में नीचे है:

CREATE TABLE [dbo].[FilePath] 
    (
     [FilePath] NVARCHAR(256) NOT NULL PRIMARY KEY, 
     [FileMd5Hash] binay(16) NOT NULL, 
     [Duplicated] BIT NOT NULL DEFAULT 0, 
     [LastRunBuild] NVARCHAR(30) NOT NULL DEFAULT 0 
    ) 

    CREATE TABLE [dbo].[Result] 
    (
     [Build] NVARCHAR(30) NOT NULL, 
     [FileMd5Hash] binay(16) NOT NULL , 
     [SegmentId] INT NOT NULL, 
     [SegmentContent] text NOT NULL 
     PRIMARY KEY ([FileMd5Hash], [Build], [SegmentId]) 
    ) 

और मैं FileMd5Hash पर इन 2 तालिका में शामिल होने के लिए एक आवश्यकता है।

के बाद से की [परिणाम] बहुत बड़ी है पंक्तियों की संख्या, मैं नीचे के रूप में तालिकाओं के लिए इन में शामिल होने का पूर्णांक पहचान स्तंभ जोड़ना चाहते हैं:

CREATE TABLE [dbo].[FilePath] 
    (
     [FilePath] NVARCHAR(256) NOT NULL PRIMARY KEY, 
     [FileMd5Hash] binay(16) NOT NULL, 
     **[Id] INT NOT NULL IDENTITY,** 
     [Duplicated] BIT NOT NULL DEFAULT 0, 
     [LastRunBuild] NVARCHAR(30) NOT NULL DEFAULT 0 
    ) 

    CREATE TABLE [dbo].[Result] 
    (
     [Build] NVARCHAR(30) NOT NULL, 
     **[Id] INT NOT NULL,** 
     [SegmentId] INT NOT NULL, 
     [SegmentContent] text NOT NULL 
     PRIMARY KEY ([FileMd5Hash], [Build], [SegmentId]) 
    ) 

तो पक्ष और विपक्ष की क्या है इन 2 तरीकों से?

http://databases.aspfaq.com/database/what-should-i-choose-for-my-primary-key.html

MD5 हैश का उपयोग करते हुए अपने प्राथमिक कुंजी के लिए एक GUID का उपयोग कर तरह होगा:

Answer 1

एक int कुंजी लागू करने और समझने में आसान और आसान है। यह भी छोटा है (4 बाइट बनाम 16 बाइट्स), इसलिए इंडेक्स प्रति आईओ पेज प्रविष्टियों की संख्या के बारे में दोगुना फिट होगा, जिसका अर्थ है बेहतर प्रदर्शन। तालिका पंक्तियां भी छोटी होंगी (ठीक है, बहुत छोटी नहीं), तो फिर आप प्रति पेज = कम आईओ अधिक पंक्तियों को फिट करेंगे।

हैश हमेशा टकराव का उत्पादन कर सकता है। यद्यपि अत्यधिक दुर्लभ, फिर भी, birthday problem दिखाता है कि रिकॉर्ड गिनती बढ़ने के साथ टकराव अधिक से अधिक हो जाते हैं। विभिन्न बिट लंबाई हैश के साथ टकराव की 50% संभावना के लिए आवश्यक वस्तुओं की संख्या इस प्रकार है:

Hash length (bits) Item count for 50% chance of collision 
       32 77000 
       64 5.1 billion 
       128 22 billion billion 
       256 400 billion billion billion billion 

भी चारों ओर गैर- ASCII बाइट्स पारित करने के लिए होने के मुद्दे को नहीं है - डिबग करने के लिए कठिन, पर भेजने तार, आदि

int अपने टेबल के लिए अनुक्रमिक प्राथमिक कुंजी का उपयोग करें। हर कोई करता है।

Answer 2

यहाँ एक बहुत ही अच्छा लेख पेशेवरों और दोनों का उपयोग कर के विपक्ष को समझा है। हैश टकराव दुर्लभ हैं लेकिन ऐसा होता है, आप इसे संभालना चाहते हैं।

मैं व्यक्तिगत रूप से अपनी पहचान के साथ जाऊंगा लेकिन यह आपके कार्यान्वयन के आधार पर भिन्न हो सकता है।

Answer 3

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

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

मैं शर्त लगाता हूं कि आपका व्यवसाय विश्लेषक कहेंगे "हम काम को लागू करते हैं ताकि हमारे रिकॉर्ड कभी नहीं बदले"। वे गलत साबित होंगे।