मैं अद्वितीय कुंजी का उपयोग करना पसंद करूंगा, क्योंकि वे पारदर्शी हैं और वे स्रोत पर डुप्लिकेशन को रोकते हैं। (यानी आप डुप्लिकेट डेटा जोड़ने के लिए अपने कोड में एक बग पेश नहीं कर सकते हैं या कोई अन्य एप्लिकेशन/व्यक्ति तालिका डेटा को सीधे संपादित करके डुप्लिकेट डेटा भी नहीं जोड़ सकता है)
बहु थ्रेडेड अनुप्रयोगों के लिए, यदि कोड/प्रश्न खराब तरीके से लिखे गए हैं तो इसका परिणाम हो सकता है डुप्लिकेट में, लेकिन एक अच्छा कार्यान्वयन विशिष्टता की गारंटी दे सकता है। (एकल लेनदेन, अस्तित्व की जांच और एक ही प्रश्न में डालें, अलग-अलग प्रश्नों में नहीं, नो-ऑटो प्रतिबद्धता आदि)
दूसरी ओर, अद्वितीय कुंजी बाधा का नकारात्मक हिस्सा डेटाबेस ओवरहेड होगा। (किसी अन्य कमियां की वास्तव में सोच भी नहीं सकता है)
तो यह इस बात आती है:
विकल्प 1:, डेटाबेस पर भरोसा करते हैं जिसका कार्य डेटा और संबंधित बाधाओं, जहां अधिकांश प्रयोगों वास्तव में अच्छा कर रहे हैं संभाल करने के लिए है दोनों प्रदर्शन- बुद्धिमान और विश्वसनीयता के अनुसार।
विकल्प 2: मैन्युअल रूप से अद्वितीय बाधा जांच कोड लिखें, जो अंततः डीबी प्रश्नों का उपयोग करके अनूठी जांच करता है। और यदि अन्य डेटाबेस-क्लाइंट समान डेटाबेस तालिका में हैं तो डुप्लिकेट डेटा को रोक नहीं देता है।
यदि आपकी प्राथमिक चिंता प्रदर्शन है, तो यह आपके डेटा और डीबी पर निर्भर करता है। आपको बेंचमार्क करना होगा।
अन्यथा, विकल्प स्पष्ट है।
किसी के पास कोई सुझाव है? – Kathir