2013-04-16 3 views
6

मेरे पास 3 भाषाओं में एक वेबसाइट है।बहुभाषी डेटाबेस: कौन सी विधि बेहतर है?

डीबी की संरचना का सबसे अच्छा तरीका कौन सा है?

1) 3 तालिका बनाएँ, हर भाषा के लिए (उदाहरण के लिए Product_en, Product_es, Product_de) और एक पहचानकर्ता के साथ तालिका से डेटा पुनः प्राप्त:

उदा

$language = 'en' 

तो मैं डेटा प्राप्त केवल

SELECT FROM Product_$language 

2) के साथ 1 तालिका बनाएँ:: php पृष्ठ पर मैं एक स्ट्रिंग है

ID LANGUAGE NAME DESCR 

और पेज पर पोस्ट केवल

WHERE LANGUAGE = '$language' 

3) 1 तालिका बनाएं:

ID NAME_EN DESCR_EN NAME_ES DESCR_ES NAME_DE DESCR_DE 

धन्यवाद!

+0

विकल्प 4: अंग्रेजी में विवरण के साथ एक तालिका है। वाक्यांशों का अनुवाद करने वाली एक और तालिका है। यदि कोई वाक्यांश पहले से मौजूद है, तो आपके पास अनुवाद है। यदि नहीं, तो इसे जोड़ें। यह एक "शब्दकोश" बनाता है। क्या यह और अधिक कुशल है? इस बात पर थोड़ा निर्भर करता है कि क्या आप कई तारों का पुन: उपयोग करते हैं या नहीं (अधिक, कभी, ...) - जो बदले में डेटाबेस पर कितना बड़ा है, इस पर निर्भर करता है। यह चीजों को आंशिक रूप से अधिक रखरखाव बनाता है, मुझे लगता है। – Floris

उत्तर

4

मैं दूसरा विकल्प के लिए जाना चाहूंगा।

मेरे लिए पहला विकल्प रिकॉर्ड्स की खोज के लिए पर्याप्त लचीला प्रतीत नहीं होता है। यदि आपको दो भाषाओं की खोज करने की आवश्यकता है तो क्या होगा? उस पर आप सबसे अच्छा तरीका कर सकते हैं UNION दो SELECT कथन का परिणाम। तीसरे में डेटा अनावश्यकता प्रतीत होती है। ऐसा लगता है कि आपको हर नाम पर एक भाषा की आवश्यकता है।

दूसरा एक बहुत लचीला और आसान है। जब तक आप रिकॉर्ड्स को पिट नहीं करना चाहते हैं, तब तक आप कुछ विशेष तरीकों को जोड़ने के बिना जो भी ऑपरेशन चाहते हैं, कर सकते हैं।

+0

# 2 जाने का रास्ता है। उन विशेषताओं के लिए एक अलग उत्पाद तालिका बनाने के लिए ध्यान रखें जो भाषा विशिष्ट नहीं हैं, जैसे मूल्य, qty, UPC, ... यह तालिका उत्पादों के लिए आपकी मास्टर टेबल होगी। – Cano64

1

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

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

+0

धन्यवाद, मैं दूसरे – user2120569

1

इस तरह आप किसी भी समय डेटाबेस को मार देंगे। यह न केवल एक बेहतर संरचित डेटाबेस के लिए है, लेकिन आप भी उत्पादों है कि केवल एक ही अनुवाद किया है हो सकता है आप की अनुमति देगा,

TABLE languages with fields: 

-- product name 
-- product description 
-- two-letter language code 

:

वैसे ही जैसे एक मेज है। यदि आप चाहते हैं कि यदि कोई अन्य निर्दिष्ट नहीं है तो आप डिफ़ॉल्ट भाषा भी दिखाना चाहेंगे। आप निश्चित रूप से प्रोग्रामेटिक रूप से करेंगे, लेकिन मुझे लगता है कि आपको विचार मिलता है।

+0

के लिए जाऊंगा यह मैंने दूसरी विधि पर लिखा है! धन्यवाद – user2120569

+0

मेरे लिए, यह सबसे अनुकूलित तरीका है :) यह आपको इसे संभालने की अनुमति देगा कि आप वास्तव में कैसे करना चाहते हैं। आप कोड पर निर्णय लेते हैं, और आप एक स्वच्छ डेटाबेस बरकरार रखते हैं :) –

संबंधित मुद्दे