NoSQL

Question

के साथ स्थानीयकरण कैसे प्राप्त करें अब तक, मैंने हमेशा संबंधपरक डेटाबेस का उपयोग किया है (और वास्तव में बहुत खुश था!)। हालांकि, हाल ही में, मैंने Parse की खोज की और इसे बहुत अच्छा लगा, इसलिए इसे आज़माने का फैसला किया। हालांकि, यह एक NoSQL डेटाबेस के साथ आता है। मैं अभी भी इसके चारों ओर अपना सिर लेने की कोशिश कर रहा हूं। तो मेरा सवाल यह है कि आप स्थानीयकरण को प्राप्त करने की सिफारिश कैसे करेंगे? मैं निम्नलिखित दृष्टिकोणों के बारे में सोच सकता हूं, आपको क्या लगता है?

• दृष्टिकोण ए: दस्तावेज़ पर एक एकल 'तार' फ़ील्ड रखें और उस क्षेत्र में सभी भाषा विशिष्ट डेटा स्टोर करें। उदाहरण के लिए,

  "strings": 
  { 
      "en" : 
      { 
       "title" : "English title" 
      } 
      "de" : 
      { 
       "title" : "Deutsch Titel" 
      } 
  } 
  

• दृष्टिकोण बी: दस्तावेज़ पर एक से अधिक क्षेत्रों, प्रत्येक क्षेत्र एक भाषा विशिष्ट फ़ाइल की ओर इशारा करते हैं। स्ट्रिंग नामक एक अन्य दस्तावेज़ को परिभाषित करें। उदाहरण के लिए,

  "strings_en": <Pointer to a *strings* object> 
  "strings_de": <Pointer to a *strings* object> 
  
  // And here's one *strings* document 
  { 
      "title" : "My English title" 
  } 
  

• दृष्टिकोण सी: बस के रूप में एक संबंधपरक डेटाबेस स्कीमा में, भाषा कोड के साथ एक अलग तार तालिका है। इस तालिका/दस्तावेज़ को अलग से क्वेरी करें और परिणामों को मर्ज करें

• दृष्टिकोण डी: (नया) दृष्टिकोण बी के समान, दो दस्तावेज़ों पर कई कॉलम का समर्थन करना, उसी दस्तावेज़ में सभी प्रासंगिक डेटा को रखने के उद्देश्य से।

  { 
      "title_en" : "English title", 
      "title_de" : "Deutsch titel", 
      "description_en" : "English description", 
      "description_de" : "Deutsch beschreibung" 
  } 
  

दृष्टिकोण एक: मुझे समझ बनती है, लेकिन मैं एक आसान तरीका (पार्स ढांचे में) वापस ग्राहक के लिए केवल प्रासंगिक डेटा भेजने के लिए पता नहीं है। यह ग्राहक के लिए सभी स्ट्रिंग्स भेज देंगे -> अनावश्यक बैंडविड्थ का उपयोग

दृष्टिकोण बी: एक संबंधपरक डाटाबेस पृष्ठभूमि से आ रहा है, मैं बहुत अधिक स्तंभ होने की संभावना (यह अंततः 30 विभिन्न के लिए 30 विभिन्न स्तंभों हो सकता है पसंद नहीं है भाषाएं) और साथ ही, ग्राहक वस्तु का उपयोग नहीं कर सकता है। तार। इसे हमेशा फील्ड नाम के अंत में भाषा कोड जोड़ना होता है, जो कठिन (और जोखिम भरा भी) होता है। लेकिन यह दृष्टिकोण मुझे सबसे ज्यादा समझ में आता है।

दृष्टिकोण सी: मैं तुम कह 'क्या NoSQL की बात है अगर आप रिलेशनल डाटाबेस डिजाइन प्रतिमान के NoSQL अनुकूल करने के लिए जा रहे हैं'

दृष्टिकोण डी सुन सकते हैं: हाँ, तुम हास्यास्पद कई कॉलम के साथ खत्म हो जाएगा लेकिन मुझे लगा कि एक महत्वपूर्ण लक्ष्य एक दस्तावेज़ में सभी आवश्यक डेटा को 1+ दस्तावेज़ों में वितरित करने के विरोध में रखना है। और खेतों की संख्या बिल्कुल कोई समस्या नहीं है। इसलिए, मैं अब इस दृष्टिकोण के साथ जा रहा हूँ।

तो, आप अपने नोएसक्यूएल डीबी स्कीमा में स्थानीयकरण कैसे प्राप्त करते हैं?

Answer 1

हाल ही में इस विषय के बारे में रावेनडीबी मंचों पर एक चर्चा हुई थी। See Here

नोएसक्यूएल में अधिकांश चीजों की तरह, कई अलग-अलग विकल्प हैं। एक विचार आया कि यह है कि कई दस्तावेज़ डेटाबेस (जैसे RavenDB) में, आप स्ट्रिंग-आधारित "अर्थात्" कुंजी हो सकते हैं। डेटा स्थानीयकरण प्रदान करने के लिए इनका उपयोग किया जा सकता है।

products/1 
{ 
    "Price" : 10.00 
{ 

products/1/en 
{ 
    "Name" : "ball" 
} 

products/1/es 
{ 
    "Name" : "bola" 
} 

products/1/fr 
{ 
    "Name" : "balle" 
} 

गैर स्थानीयकृत किए जाने योग्य गुण products/1 जो मुख्य दस्तावेज़ महत्वपूर्ण है में जमा हो जाती:

उदाहरण के लिए, कई एक साथ काम करने के लिए एक उत्पाद का प्रतिनिधित्व करने के लिए दस्तावेजों पर विचार करें। लेकिन फिर स्थानीयकरण योग्य तार अन्य दस्तावेजों में जा सकते हैं जो उनकी कुंजी से संबंधित हैं।

यह काम अच्छी तरह से करने के लिए - विभिन्न दस्तावेज़ों के साथ काम करने के कुछ प्रबंधन ओवरहेड हैं। RavenDB में - यह एक कस्टम "बंडल" द्वारा प्रदान किया जाएगा। (यह अभी तक अस्तित्व में नहीं है - मैं इस पर काम कर रहा हूं।) अन्य डेटाबेस में विभिन्न कार्यान्वयन विवरण हो सकते हैं जो इस दृष्टिकोण को व्यवहार्य होने की अनुमति दे सकते हैं।

Answer 2

Ayende तरह

{ 
    "States": [ 
    { 
     "Name": [ 
     { 
      "Culture": "en", 
      "Value": "Texas" 
     }, 
     { 
      "Culture": "fr", 
      "Value": "French Texas" 
     } ], 
     "Abbrevation": "TX" 
    }] 
}