Quelles sont les meilleures pratiques pour la conception de base de données multilingues ?

Question

Quelle est la meilleure façon de créer la base de données multilingue ? Pour créer localisée table pour chaque table fait design et interrogation complexe, dans les autres cas pour ajouter des colonnes pour chaque langue est simple, mais pas dynamique, s’il vous plaît m’aider à comprendre quel est le meilleur choix pour les applications d’entreprise

Answer 1

Ce que nous faisons, c'est de créer deux tables pour chaque multilingue de l'objet.

E. g. le premier tableau contient uniquement la langue neutre de données (clé primaire, etc.) et le deuxième tableau contient un enregistrement par la langue, contenant les données localisées, plus le code ISO de la langue.

Dans certains cas, nous ajoutons un DefaultLanguage champ, de sorte que nous pouvons recul de cette langue si aucune des données localisées est disponible pour une langue donnée.

Exemple:

Table "Product":
----------------
ID                 : int
<any other language-neutral fields>


Table "ProductTranslations"
---------------------------
ID                 : int      (foreign key referencing the Product)
Language           : varchar  (e.g. "en-US", "de-CH")
IsDefault          : bit
ProductDescription : nvarchar
<any other localized data>

Avec cette approche, vous pouvez gérer autant de langues que nécessaire (sans avoir à ajouter des champs supplémentaires pour chaque nouvelle langue).

Answer 2

Je recommande la réponse posté par Martin.

Mais vous avez l'air d'être préoccupé par vos requêtes trop complexe:

Pour créer localisée table pour chaque table est de rendre la conception et l'interrogation complexe...

Donc, vous pensez peut-être qu'au lieu d'écrire des requêtes simples, comme ceci:

SELECT price, name, description FROM Products WHERE price < 100

...vous auriez besoin pour commencer à écrire des requêtes comme ça:

SELECT
  p.price, pt.name, pt.description
FROM
  Products p JOIN ProductTranslations pt
  ON (p.id = pt.id AND pt.lang = "en")
WHERE
  price < 100

Pas un très joli point de vue.

Mais au lieu de le faire manuellement, vous devez développer votre propre accès à la base de la classe, que la pré-analyse le SQL qui contient votre localisation particulière de balisage et convertit les réels SQL, vous devez envoyer à la base de données.

Grâce à ce système pourrait ressembler à quelque chose comme ceci:

db.setLocale("en");
db.query("SELECT p.price, _(p.name), _(p.description)
          FROM _(Products p) WHERE price < 100");

Et je suis sûr que vous pouvez faire encore mieux que ça.

La clé est d'avoir de vos tables et de champs nommés en uniforme.

Answer 3

Je trouve ce type d'approche qui fonctionne pour moi:

Produit ProductDetail Pays
========= ================== =========
ProductId ProductDetailId CountryId
- etc - ProductId CountryName
 CountryId Langue
 ProductName - etc -
ProductDescription
 - etc -

Le ProductDetail table contient toutes les traductions (pour le nom du produit, description, etc..) dans les langues que vous voulez soutenir. En fonction des besoins de votre application, vous pouvez rompre le tableau des Pays bas à l'utilisation des langues régionales.

Answer 4

J’utilise l’approche suivante :

Produit

ProductID OrderID...

ProductInfo

LanguageID nom titre ProductID

Langue

LanguageID nom Culture...

Answer 5

Solution de Martin est très similaire à la mienne, mais Comment géreriez-vous une description par défaut lorsque la traduction souhaitée n’est pas trouvée ?

Qui nécessiterait une IFNULL() et une autre instruction SELECT pour chaque champ ?

La traduction par défaut serait stockée dans la même table, où un drapeau comme « isDefault » indique météo que la description est la description par défaut dans le cas où aucun n’a été trouvée pour le langage courant.