टेबल्स के लिए भाषा अनुवाद

Question

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

CREATE TABLE Product 
(
    Product_id 
    ,ProductTrans_id -- FK 
) 

CREATE TABLE ProductTranslation 
(
    ProductTrans_id 
    ,Product_id 
    ,Name 
    ,Descr 
    ,lang_code 
) 

क्या नीचे दिया गया दृष्टिकोण व्यवहार्य होगा? मान लें कि आपके पास बहुत सारी टेबल हैं जहां 1 से अधिक कॉलम अनुवाद की आवश्यकता है। क्या आप निम्नलिखित अनुवादों को 1 टेबल में सभी अनुवादों को रख सकते हैं? मुझे लगता है कि यह तालिका समय के साथ आकार में काफी हद तक बढ़ेगी।

CREATE TABLE translation_entry (
      translation_id  int, 
      language_id   int, 
      table_name   nvarchar(200), 
      table_column_name  nvarchar(200), 
      table_row_id   bigint, 
      translated_text  ntext 
     ) 

    CREATE TABLE translation_language (
      id int, 
      language_code CHAR(2) 
     ) 

तो दूसरा दृष्टिकोण का उपयोग करते हुए आप ऐसा

select 
    product.name 
    ,translation_entry.translated_text 
from product 
inner join translation_entry on product.product_id = translation_entry.table_row_id 
and translation_entry.table_name = 'Product' and translation_entry.table_column_name = 'Name' 
and language_id = 3 

Answer 1

की तरह पाठ मुझे यकीन है कि तुम क्यों तालिकाओं की संख्या को लेकर चिंतित हैं नहीं कर रहा हूँ मिलता है: कम तालिकाओं होने स्वचालित रूप से इसका मतलब यह नहीं आपका डेटाबेस छोटा, अधिक कुशल या बेहतर डिज़ाइन किया गया है। खासकर अगर टेबल की संख्या को कम करने से आपके प्रश्नों की जटिलता बढ़ जाती है, तो मैं इसे करने के बारे में बहुत सावधान रहूंगा।

वैसे भी, मैं प्रति 'आधार' तालिका में एक अनुवाद तालिका के लिए जाऊंगा। मुख्य कारण यह है कि आपका दूसरा समाधान लचीला नहीं है: यदि प्राथमिक कुंजी एक पूर्णांक नहीं है तो इसे लागू करना और उपयोग करना बेहद मुश्किल हो जाता है। अनुवादों के लिए पूछताछ भी अधिक जटिल है, और तालिका और डेटा के आकार के आधार पर, इसे प्रभावी ढंग से अनुक्रमित करना मुश्किल हो सकता है।

यह स्पष्ट नहीं है कि तालिका पर आपके पास TranslationID क्यों है;

create table dbo.Products (
    ProductCode char(10) not null primary key, 
    ProductName nvarchar(50) not null, 
    ProductDescription nvarchar(100) not null, 
    -- other columns 
) 

create table dbo.ProductsTranslations (
    ProductCode char(10) not null, 
    LanguageCode char(2) not null, 
    ProductName nvarchar(50) not null, 
    ProductDescription nvarchar(100) not null, 
    -- other translations 
    constraint FK1 foreign key (ProductCode) 
     references dbo.Products (ProductCode), 
    constraint FK2 foreign key (LanguageCode) 
     references dbo.Languages (LanguageCode), 
    constraint PK primary key (ProductCode, LanguageCode) 
) 

अपने टूलसेट और तैनाती प्रक्रिया आप अपने डेटाबेस का निर्माण के हिस्से के रूप बेस लोगों से सीधे अनुवाद तालिकाओं उत्पन्न करने के लिए चाहते हो सकता है पर निर्भर करता है

: आम तौर पर संबंध दूसरी तरह के आसपास है। और आप आधार तालिका के सुविधाजनक, 'पूरी तरह से अनुवादित' संस्करण प्रदान करने के लिए विचारों का उपयोग कर सकते हैं।

एक दिलचस्प सवाल यह है कि Products में कॉलम के लिए भाषा का उपयोग किस प्रकार किया जाता है और यदि अनुवाद की आवश्यकता होने पर उन्हें सीधे उपयोग किया जा सकता है। मेरा सुझाव यह होगा कि सभी उत्पादन कोड को भाषा पैरामीटर पास करना चाहिए और पाठ को केवल ProductsTranslations तालिका से ले जाना चाहिए, यहां तक ​​कि अंग्रेजी के लिए भी (या जो भी आपकी आंतरिक कॉर्पोरेट भाषा है)। इस तरह आप यह सुनिश्चित कर सकते हैं कि सभी 'आधिकारिक' नाम एक ही तालिका में पाए जाते हैं, और आधार तालिका के कॉलम डेटा मॉडल की स्पष्टता और पूर्णता के साथ-साथ डेवलपर सुविधा और (संभावित रूप से) विज्ञापन के उपयोग पर आंतरिक उपयोग के लिए हैं रिपोर्ट और इतने पर।