Design de banco de dados para aplicativos em vários idiomas

Quais informações precisamos armazenar em vários idiomas?

Que abordagens consideramos?

Abordagem 1:criando colunas adicionais para manter o conteúdo traduzido

Contra:Complexidade do código

SELECT ProductID, CASE @Language WHEN 'ES' THEN ProductName_ES QUANDO 'DE' THEN ProductName_DE WHEN 'FR' THEN ProductName_FR ELSE ProductName END AS ProductName, CASE @Language QUANDO 'ES' THEN ProductDescription_ES WHEN 'DE' THEN ProductDescription_DE WHEN ' FR' THEN ProductDescription_FR ELSE ProductDescription END AS ProductDescription, Price, Weight, ProductCategoryIDFROM ProductWHERE …

Contra:falta de flexibilidade

Con:Desafios ao lidar com informações desconhecidas

Abordagem 2:Isolando colunas traduzíveis em uma tabela separada

SELECT p.ProductID, pt.ProductName, pt.ProductDescription, p.Price, p.Weight, p.ProductCategoryIDFROM Product pLEFT JOIN ProductTranslation pt ON pt.ProductID =p.ProductID AND pt.LanguageID =@LanguageWHERE … 
 No entanto, ainda existem alguns contras, como discutimos abaixo. 
 
Contra:Desafios quando colunas adicionais precisam ser traduzidas
 
 Se precisarmos converter uma coluna não traduzível em uma traduzível (ou vice-versa), precisamos modificar nosso modelo de dados, movendo a coluna de uma tabela para outra. Isso geralmente implica em maiores custos uma vez que o sistema esteja implementado e em uso. 
 
Con:Desafios ao lidar com informações desconhecidas
 
 Assim como a primeira abordagem, essa abordagem apresenta desafios ao lidar com informações desconhecidas. Novamente, se um usuário adiciona um produto, mas não sabe como traduzi-lo e deixa as colunas traduzidas vazias, os usuários que falam esses idiomas veem NULL ou informações em branco nas colunas que podem ser necessárias. Além disso, a consulta requer um LEFT JOIN caso a tradução para o idioma do usuário atual ainda não tenha sido criada para que os dados não traduzíveis ainda sejam mostrados. 
 
Abordagem 3:Adicionando um Subsistema de Tradução
 
 A tradução pode ser considerada como um recurso completamente independente do modelo de dados que requer tradução. Em um sistema ideal, podemos habilitar ou desabilitar a tradução para qualquer coluna sem exigir modificação no modelo de dados. Infelizmente, isso é mais fácil dizer do que fazer. 
 
 Apresentamos um método que não tem impacto no modelo de dados existente e é completamente flexível. Embora acrescente complexidade na hora de consultar os dados, não requer nenhuma alteração adicional no modelo de dados, exceto algumas tabelas. Essa pode ser uma ótima opção se você precisar adicionar a capacidade de manter traduções em um modelo de dados existente. 
 
 Vamos dar uma olhada no modelo e ver como ele funciona:
 
 A primeira coisa a notar é que o modelo de dados original não tem nenhuma alteração. Além disso, não há relação direta entre esse modelo e o subsistema de tradução. 
 
 O subsistema de tradução inclui um pequeno dicionário de dados com as tabelas e colunas que requerem tradução. Este dicionário de dados pode ser modificado apenas adicionando/removendo linhas sem alterar o modelo de dados. As traduções são armazenadas em uma tabela separada, com cada valor identificado pelas 3 colunas a seguir:
 
 
ColumnID :identifica exclusivamente a coluna (e a tabela) que estamos traduzindo.
 
KeyID :armazena o ID (chave primária) da linha específica que estamos traduzindo.
 
LanguageID :identifica o idioma da tradução.
 
 
 Esse design permite que os dados sejam inseridos e armazenados nas tabelas originais, adicionando traduções somente se e quando necessário. As informações traduzidas são usadas na recuperação de dados, mantendo os dados originais (no idioma original) intocados. 
 
 Os dados podem ser consultados usando uma sintaxe mais complexa do que os exemplos acima. Requer um JOIN adicional para cada coluna traduzível, conforme mostrado abaixo:
 
SELECT p.ProductID, ISNULL(t1.TranslationValue, p.ProductName) AS ProductName, ISNULL(t2.TranslationValue, p.ProductDescription) AS ProductDescription, p.Price, p.Weight, p.ProductCategoryIDFROM Product pLEFT JOIN Tradução t1 ON t1.ColumnID =<> AND t1.Key =p.ProductID AND t1.LanguageID =@LanguageLEFT JOIN Tradução t2 ON t2.ColumnID =<> AND t2.Key =p.ProductID AND t2.LanguageID =@LanguageWHERE …;
 
 Observação: “<<ProductName_ColumnID>> ” e “<<ProductDescription_ColumnID>> ” deve ser substituído pelos IDs das colunas a serem traduzidas como armazenadas em ColumnInformation  tabela. Considere gerar visualizações de tradução para cada tabela que requer tradução para ocultar a complexidade dos JOINs para os usuários finais. Você pode até automatizar essa etapa com um script que gera cada visualização. Este script pode consultar o dicionário de dados do banco de dados para escolher as tabelas e colunas e adicionar a lógica de tradução para as colunas que existem no ColumnInformation  tabela. 
 
 Dica Extra nº 1 
 
 Você também pode simplificar a sintaxe. Substitua cada JOIN por uma chamada para uma função que trata (e oculta) o aspecto da tradução, conforme mostrado abaixo:
 
SELECT p.ProductID, ISNULL(fn_translate('Product','ProductName',ProductID), p.ProductName) AS ProductName, ISNULL(fn_translate('Product','ProductDescription',ProductID), p.ProductDescription) AS ProductName, p.Price, p.Weight, p.ProductCategoryIDFROM Product pWHERE …;
 
 A função pode ler o idioma desejado do contexto ou você pode adicioná-lo como um parâmetro adicional. Neste exemplo, a função usa os nomes de tabela e coluna fornecidos como parâmetros mais a chave de linha (também fornecida como parâmetro) para pesquisar e retornar a tradução desejada. 
 
 Chamar uma função implica um impacto adicional no desempenho devido à alternância de contexto entre SQL e linguagem procedural. No entanto, pode ser uma solução mais simples para bancos de dados ou tabelas onde a quantidade de dados sendo traduzidos o permita. 
 
 Ambos os exemplos – aquele com um JOIN e aquele com uma função – usam a função ISNULL() do SQL Server. Assim, quando a tradução para o idioma desejado não existe, ela ainda exibe o valor original armazenado nas colunas ProductName e ProductDescription em vez de espaços em branco ou NULL. 
 
Considerações Gerais
 
 A terceira abordagem geralmente é a melhor para implementar projetos maiores. Ele permite flexibilidade tanto no projeto quanto uma vez que o sistema está em uso. No entanto, existem considerações específicas que podem tornar as outras abordagens úteis. Independentemente de sua escolha, considere o seguinte para economizar tempo tanto no projeto quanto no desenvolvimento/implementação. 
 
Adicione uma camada de abstração
 
 Como mencionado anteriormente, considere a criação de visualizações que cuidam da lógica de tradução, por exemplo, selecionando uma coluna entre várias colunas de tradução ou juntando-se a linhas específicas. Isso mantém detalhes de implementação específicos ocultos dos programadores. Eles simplesmente usam essas visões em vez de ter que construir sentenças SQL complexas toda vez que precisam acessar uma tabela com informações traduzíveis. 
 
Use o contexto para filtrar dados
 
 Conforme mencionado no primeiro exemplo, considere o uso de funções de contexto disponíveis na maioria dos mecanismos de banco de dados. Use-os para armazenar informações de idioma do usuário uma vez logado no sistema e filtre os resultados automaticamente nas visualizações que cuidam da tradução. 
 
Automatizar
 
 Os sistemas modernos podem ter centenas e até milhares de tabelas. Reserve um tempo para automatizar a geração das visualizações de tradução em vez de escrever as consultas uma a uma. Pode levar algum tempo para você chegar a um script que funcione, mas você sempre pode criar novas visualizações ou recriar as existentes em menos de um segundo!