मूल रूप से आपके पास 3 विकल्प हैं:
-
बस
userIdस्टोर करें और फिर उपयोगकर्ता को अलग से लाएं। इस तरह आपको ताजा डेटा के मामले में हमेशा इष्टतम परिणाम मिलते हैं। लेकिन निश्चित रूप से यह धीमा है। यह मूल रूप से एक रिलेशनल डेटाबेस करता है। एक SQL DB केवल विदेशी कुंजी पर एक नज़र डालेगा और आईडी द्वारा डेटा प्राप्त करेगा। -
पुराने डेटा के साथ लाइव। टिप्पणियों के अंदर उपयोगकर्ता नाम का एक डुप्लिकेट स्टोर करें। कभी-कभी यह वांछित व्यवहार होता है, क्योंकि इस तरह आप डेटा का ठीक उसी तरह प्रतिनिधित्व कर सकते हैं जैसे वह तब था जब इसे संग्रहीत किया गया था। इसका अर्थ है:यदि जॉन एक टिप्पणी बनाता है और बाद में उसका उपयोगकर्ता नाम पॉल में अपडेट हो जाता है, तो आप अभी भी देख सकते हैं, वह जॉन के रूप में बनाया गया है। (यह विशेष रूप से इनवॉइस के लिए उपयोगी है, जब आप वहां किसी व्यक्ति का संदर्भ देते हैं और पता बदल जाता है, तो आप किसी पुराने चालान का पता अपडेट नहीं करना चाहते हैं)
-
उपयोगकर्ता नाम अपडेट होने पर, उपयोगकर्ता नाम वाले सभी चीज़ों को अपडेट करें। यह भी बुरा नहीं है, क्योंकि उपयोगकर्ता नाम सामान्य रूप से कभी नहीं बदलना चाहिए। इसलिए रीड हमेशा फास्ट रहेगा, क्योंकि कमेंट के अंदर नाम स्टोर होता है। और अगर नाम बदलता है, तो आपको वह सब कुछ अपडेट करना होगा जहां उपयोगकर्ता शामिल है। बेशक यह एक धीमा काम है, लेकिन क्योंकि यह हर मिनट नहीं होना चाहिए, यह सहनीय है।
3.1 आप चीजों को अनुकूलित कर सकते हैं:यदि उपयोगकर्ता नाम बदलता है, तो यह कहीं संग्रहीत हो जाता है और मध्यरात्रि में लागू किया जाता है। इस तरह आप एक ही समय में कई नाम परिवर्तन एकत्र कर सकते हैं और सब कुछ अपडेट कर सकते हैं।
जैसा कि आप देख सकते हैं:NoSQL पसंद के बारे में है . आप वे काम कर सकते हैं जो आपके डेटा के लिए सबसे उपयुक्त हों। बेशक यह हमेशा एक ट्रेडऑफ़ है:धीमा/तेज़, लिखने के लिए अधिक/कम कोड, बनाए रखने में आसान/कठिन।
संक्षेप में यह है:
- तेज़ लेखन, सुसंगत डेटा, धीमी गति से पढ़ता है
- तेज़ लिखना, असंगत डेटा, तेज़ पढ़ना
- तेजी से लिखता है, तेजी से पढ़ता है, अद्यतन प्रक्रिया के बाद डेटा सुसंगत हो जाता है जिसमें कुछ समय लग सकता है। और निश्चित रूप से अद्यतन प्रक्रिया धीमी है।
