2011-06-14 8 views
5

Tengo una aplicación escrita para el mercado del Reino Unido que actualmente solo admite inglés (Reino Unido) y un cliente desea implementar parte de la aplicación en un sitio que no sea del Reino Unido y sincronizar los datos a la sede del Reino Unido.Traducir cadenas de bases de datos

Puedo convertir las etiquetas y los mensajes de las aplicaciones usando los archivos de recursos y la información cultural local, pero me preguntaba cómo convertiría los datos encuadernados a la base de datos.

E.G. Aquí está la tabla basada HQ

tblFault 
ID ; Description 
1 ; Not Functional 
2 ; Build Fault 
3 ; Leak 
4 ; Aesthetics 
5 ; Testing 

Si tuviera que traducir los datos a la lengua fuera del Reino Unido tan sólo pudiera sustituir a las denominaciones, pero esto causaría algunos problemas si los datos son no sincronizado?

¿Debo extender la tabla con otra columna para un idioma adicional y luego modificar la selección utilizando la cultura local?

tblFault 
ID ; Description-EN ; Descrption-US ; Description-DE etc 
1 ; Not Functional ;    ; 
2 ; Build Fault ;    ; 
3 ; Leak   ;    ; 
4 ; Aesthetics  ;    ; 
5 ; Testing  ;    ; 

¿Qué método recomendarías?

Gracias

Phil

Respuesta

5

Puesto que usted tiene una relación 1: n entre las fallas y sus descripciones, la solución más limpio sería la creación de una subtabla:

tblFault 
-------- 

FaultID ; some other fields 
     1 ; ... 
     2 ; ... 
     3 ; ... 
     4 ; ... 
     5 ; ... 


tblFault_Description 
-------------------- 

FaultID ; lang ; Description 
     1 ; en ; Not Functional 
     1 ; de ; Funktioniert nicht 
     2 ; en ; ... 
+2

Mantengo las versiones de idioma inglés/neutro en la tabla original (y las marcas no son nulas) por lo que siempre hay una alternativa si algo no se ha traducido aún. –

+0

Puedo ver la ventaja de este método, pero como los datos se agregan en un cubo de datos OLAP, se perdería la agregación general del nivel superior (todos los idiomas), ya que la falla tendría ID diferentes –

+2

@Phil Murray. Creo que la intención es que 'ID' en' tblFault_Labels' es un FK a 'tblFault-> ID' - cada falla tiene un' ID' único, independientemente del idioma utilizado para seleccionarlo. –

0

algo más parecido por lo tanto, con toda probabilidad:

tblFault 
ID ; Lang ; Description 
1 ; EN ; Not Functional 
... 
1

Ese es definitivamente un enfoque.

Otro enfoque que he usado en situaciones como esta antes era crear una columna "LanguageId".

Normalmente me hubiera algo como esto:

StringId, LanguageId, Description 
1   0    Hello 
1   1    Hola 
1   2    Bon Jour 

Esto permite que escriba una consulta que si la cadena 35 (por ejemplo) no tiene el idioma que estoy buscando, todavía podía proporcionar Inglés. Con la idea de que algo es mejor que nada.

La desventaja de este enfoque son las claves primarias compuestas y algunas combinaciones de lógica.

Cuestiones relacionadas