एक स्टोर (कैश, या डेटाबेस) के भीतर देखने के लिए टोकन बनाने के लिए लंबे तारों को हैश करने का आपका विचार एक अच्छा है। मैंने इसे बहुत बड़े स्ट्रिंग्स के लिए, और उच्च मात्रा वाले वातावरण में देखा है, और यह बहुत अच्छा काम करता है।
"इस एप्लिकेशन के लिए आप किस हैश का उपयोग करेंगे?"
- मुझे नहीं लगता कि एन्क्रिप्शन (हैशिंग) एल्गोरिदम वास्तव में मायने रखता है, क्योंकि आप डेटा को एन्क्रिप्ट करने के लिए हैशिंग नहीं कर रहे हैं, आप एक टोकन बनाने के लिए हैशिंग कर रहे हैं जिस पर लंबे मूल्यों को देखने के लिए एक कुंजी के रूप में उपयोग किया जा सकता है। इसलिए हैशिंग एल्गोरिथम का चुनाव गति के आधार पर होना चाहिए।
"क्या आप कोड में हैश की गणना करेंगे या डीबी को इसे संभालने देंगे?"
- अगर यह मेरा प्रोजेक्ट होता, तो मैं ऐप लेयर पर हैशिंग करता और फिर इसे स्टोर (कैश, फिर डेटाबेस) के भीतर देखने के लिए पास करता।
"क्या डेटाबेस में लंबी स्ट्रिंग को संग्रहीत/खोजने के लिए कोई मौलिक रूप से भिन्न दृष्टिकोण है?"
- जैसा कि मैंने उल्लेख किया है, मुझे लगता है कि आपके विशिष्ट उद्देश्य के लिए, आपका प्रस्तावित समाधान एक अच्छा है।
तालिका अनुशंसाएं (केवल प्रदर्शनकारी):
user
- आईडी int(11) अहस्ताक्षरित अशक्त नहीं है
- name_first varchar(100) रिक्त नहीं
user_agent_history
user_idint(11) अहस्ताक्षरित अशक्त नहीं हैagent_hashवर्कर (255) शून्य नहीं है
agent
agent_hashवर्कर (255) शून्य नहीं हैbrowserवर्कर (100) शून्य नहीं हैagentटेक्स्ट शून्य नहीं है
स्कीमा पर कुछ नोट्स:
-
आपके ओपी से ऐसा लगता है कि आपको उपयोगकर्ता और एजेंट के बीच एम:एम संबंध की आवश्यकता है, इस तथ्य के कारण कि उपयोगकर्ता काम से फ़ायरफ़ॉक्स का उपयोग कर रहा है, लेकिन फिर घर पर आईई 9 पर स्विच कर सकता है। इसलिए पिवट टेबल की जरूरत है।
-
varchar(255)
agent_hash. के लिए उपयोग किया जाता है बहस के लिए है। MySQL सुझाव हैश स्टोर करने के लिए एक varbinary कॉलम प्रकार का उपयोग करना, जिनमें से कई प्रकार हैं। -
मैं यह भी सुझाव दूंगा कि या तो
agent_hash. बनाएं प्राथमिक कुंजी, या कम से कम, कॉलम में एक अद्वितीय बाधा जोड़ना।
