अंतर्राष्ट्रीयकरण के साथ MySQL डेटाबेस डिज़ाइन

Question

मैं मध्यम आकार के एप्लिकेशन पर काम शुरू करने जा रहा हूं, और मैं इसकी डीबी डिज़ाइन की योजना बना रहा हूं। एक चीज जो मुझे यकीन नहीं है यह है। "Membership_options, gender_options, language_options आदि"

इन तालिकाओं में से प्रत्येक की तरह आम i18n क्षेत्रों, साझा करेंगे: "शीर्षक, alternative_title, SHORT_DESCRIPTION, विवरण"

मैं कई टेबल, जैसे जो अंतर्राष्ट्रीयकरण की आवश्यकता होगी होगा

आपकी राय में यह करने का सबसे अच्छा तरीका कौन सा है? एक टेबल के साथ i18n तालिका है जिसमें से प्रत्येक तालिका के लिए उन्हें आवश्यकता होगी?

या ऐसा कुछ की तरह:

Membership table  Gender table 
----------------  -------------- 
id | created_at  id | created_at 
1 - 22.03.2001  1 - 14.08.2002 
2 - 22.03.2001  2 - 14.08.2002 


General translation table 
------------------------- 
record_id | table_name | string_name | alternative_title| .... |id_language 
1  - membership regular   null      1 (english) 
1  - membership normale   null      2 (italian) 
1  - gender  man    null      1(english) 
1  -gender  uomo   null      2(italian) 

कुछ इस तरह दोहरा मुझे से बचने होगा:

membership_translation table 
----------------------------- 
membership_id | name | alternative_title | id_lang 
1    regular null    1 
1    normale null    2 

gender_translation table 
----------------------------- 
gender_id | name | alternative_title | id_lang 
1   man  null    1 
1   uomo null    2 

और इतने पर, तो मैं शायद db तालिकाओं की संख्या कम हो जाएगा, लेकिन मैं कर रहा हूँ प्रदर्शन के बारे में निश्चित नहीं है। मैं एक डीबी डिजाइनर नहीं हूं, इसलिए कृपया मुझे बताएं।

Answer 1

मैंने यह देखा है कि सबसे आम तरीका दो टेबल, membership और membership_ml के साथ है, जिसमें बेस वैल्यू और एमएल टेबल को स्थानीय तारों को संग्रहीत किया जाता है। यह आपके दूसरे विकल्प के समान है। इस तरह के अधिकांश सिस्टम मुझे इस तरह से बनाए जाते हैं क्योंकि उन्हें जाने के बाद अंतर्राष्ट्रीयकरण के साथ डिजाइन नहीं किया गया था, इसलिए अतिरिक्त _एमएल टेबल बाद में "परहेज़" किए गए थे।

मुझे लगता है कि एक बेहतर विकल्प आपके पहले विकल्प के समान है, लेकिन थोड़ा अलग है। आपके पास सभी अनुवादों को संग्रहीत करने के लिए एक केंद्रीय तालिका होगी, लेकिन वहां तालिका का नाम और फ़ील्ड नाम डालने की बजाय, आप सभी अनुवादों को स्टोर करने के लिए टोकन और केंद्रीय "सामग्री" तालिका का उपयोग करेंगे। इस तरह आप बेस टेबल में टोकन और सामग्री तालिका में अनुवादों के बीच कुछ प्रकार के आरआई को लागू कर सकते हैं यदि आप चाहें तो भी।

मैं वास्तव में कुछ समय पहले इस बारे में asked a question इस बारे में बहुत कुछ जानता हूं, तो आप कुछ और जानकारी के लिए इसे देख सकते हैं (यहां स्कीमा उदाहरणों को दोबारा बदलने के बजाय)।

Answer 2

मुझे यह भी लगता है कि विभिन्न तालिकाओं पर अनुवाद रखने का सबसे अच्छा समाधान है। यह दृष्टिकोण ओपन कार्ट का उपयोग करता है जो ओपन सोर्स है और आप इस समस्या से निपटने के तरीके को देख सकते हैं। सूचना का एक अन्य स्रोत यहां "http://www.gsdesign.ro/blog/multilanguage-database-design-approach/" है विशेष रूप से टिप्पणियों के अनुभाग