Çok dilli bir yazılım geliştiriyorum. Uygulama kodu gelince, yerelleştirme bir sorun değildir. Özel dil kaynakları kullanmak ve onlarla çalışan araçlar her türlü yapabiliriz.

Ama çok dilli bir veritabanı şemasını tanımlayan en iyi yaklaşım nedir? Hadi tablolar (100 ya da daha fazla) bir sürü var, ve her tablo, yerelleştirilmiş bir birden çok sütun (nvarchar sütunlar en yerelleştirilebilir olmalıdır) olabilir. Mesela tablolardan biri ürün bilgileri tutun:

CREATE TABLE T_PRODUCT (
  NAME        NVARCHAR(50),
  DESCRIPTION NTEXT,
  PRICE       NUMBER(18, 2)
)

Üç yaklaşımın ADI ve AÇIKLAMA sütunları çok dilli metin desteği için düşünebilirsiniz:

1. Her dil için ayrı bir sütun

   Sisteme yeni bir dil eklendiğinde, tercüme metni saklamak için ek sütunlar, bu şekilde oluşturmak zorundayız:

   CREATE TABLE T_PRODUCT (
     NAME_EN        NVARCHAR(50),
     NAME_DE        NVARCHAR(50),
     NAME_SP        NVARCHAR(50),
     DESCRIPTION_EN NTEXT,
     DESCRIPTION_DE NTEXT,
     DESCRIPTION_SP NTEXT,
     PRICE          NUMBER(18,2)
   )
   

2. Her dil için bir sütun ile Çeviri tablosu

   Çeviri metin saklamak yerine, çeviriler tablo için yabancı anahtar saklanır. Çeviriler tablo her dil için bir sütun içerir.

   CREATE TABLE T_PRODUCT (
     NAME_FK        int,
     DESCRIPTION_FK int,
     PRICE          NUMBER(18, 2)
   )
   
   CREATE TABLE T_TRANSLATION (
     TRANSLATION_ID,
     TEXT_EN NTEXT,
     TEXT_DE NTEXT,
     TEXT_SP NTEXT
   )
   

3. Her dil için bir satır ile Çeviri tabloları

   Çeviri metin saklamak yerine, çeviriler tablo için yabancı anahtar saklanır. Çeviriler tablo sadece bir anahtarı içerir ve ayrı bir masa bir dil için her çeviri için bir satır içerir.

   CREATE TABLE T_PRODUCT (
     NAME_FK        int,
     DESCRIPTION_FK int,
     PRICE          NUMBER(18, 2)
   )
   
   CREATE TABLE T_TRANSLATION (
     TRANSLATION_ID
   )
   
   CREATE TABLE T_TRANSLATION_ENTRY (
     TRANSLATION_FK,
     LANGUAGE_FK,
     TRANSLATED_TEXT NTEXT
   )
   
   CREATE TABLE T_TRANSLATION_LANGUAGE (
     LANGUAGE_ID,
     LANGUAGE_CODE CHAR(2)
   )
   

Her çözüm için artıları ve eksileri vardır, ve deneyimlerini bilmek bu yaklaşımlar, ve nasıl çok dilli bir veritabanı şema tasarımı hakkında gitmek istiyorsunuz ne tavsiye edersiniz istiyorum.

Her çevrilebilir masa ilgili çeviri bir tablo olması hakkında ne düşünüyorsunuz?

TABLO T_PRODUCT (pr_id int, FİYAT SAYISI(18, 2)) OLUŞTURUN

TABLO T_PRODUCT_tr (,, pr_name metin, pr_descr varchar metin pr_id İNT FK languagecode) OLUŞTURUN

Eğer sadece daha kolay olabilir bir translationid autogenerating olmadığı için bir tek katılmak gerekir çevrilebilir birden fazla sütun varsa bu şekilde ilgili kendi çevirileri ile birlikte öğeleri almak için.

Bu olumsuz tarafı ise karmaşık bir dil bir geri dönüş mekanizması varsa eğer bazı saklı yordam bunu kalınır her tercüme tablo için uygulamak gerekebilir. Eğer app bunu yaparsanız, bu muhtemelen bir sorun olmayacak.

Bana ne düşündüğünüzü bildirin - ayrıca bir sonraki uygulama için bu konuda bir karar vermek üzereyim. Şu ana kadar 3 türü kullandık.