mysql - Modelado de bases de datos para fines internacionales y multilingües

database database-design

Question

Necesito crear un modelo DB a gran escala para una aplicación web que será multilingüe.

Una duda que tengo cada vez que pienso en cómo hacerlo es cómo puedo resolver tener múltiples traducciones para un campo. Un ejemplo de caso.

La tabla de niveles de idioma, que los administradores pueden editar desde el backend, puede tener varios elementos como: básico, avanzado, fluido, de texto ... En el futuro cercano, probablemente sea un tipo más. El administrador va al backend y agrega un nuevo nivel, lo ordenará en la posición correcta ... ¿pero cómo manejo todas las traducciones para los usuarios finales?

Otro problema con la internacionalización de una base de datos es que probablemente los estudios de los usuarios pueden diferir de EE. UU. A UK a DE ... en cada país tendrán sus niveles (que probablemente será equivalente a otro pero finalmente, diferente). ¿Y qué hay de la facturación?

¿Cómo modelas esto a gran escala?

Answer 1

Algunas preguntas previas de StackOverflow sobre este tema:

• Diseño de esquema de base de datos para un sitio web multilingüe
• ¿Cuáles son las mejores prácticas para el diseño de bases de datos en varios idiomas?
• ¿Cuál es la mejor estructura de base de datos para mantener los datos multilingües?
• Esquema para una base de datos multilenguaje
• ¿Cómo usar el esquema de base de datos multilenguaje con ORM?

Algunos recursos externos útiles:

• Crear sitios web multilingües: diseño de bases de datos
• Enfoque de diseño de base de datos multilenguaje
• Propel Obtiene Comportamiento I18n, y por qué es importante

El mejor enfoque a menudo es, para cada tabla existente, crear una nueva tabla en la que se muevan los elementos de texto; el PK de la nueva tabla es el PK de la tabla anterior junto con el idioma.

En tu caso:

1. La tabla de niveles de idioma, que los administradores pueden editar desde el backend, puede tener varios elementos como: básico, avanzado, fluido, de texto ... En el futuro cercano, probablemente sea un tipo más. El administrador va al backend y agrega un nuevo nivel, lo ordenará en la posición correcta ... ¿pero cómo manejo todas las traducciones para los usuarios finales?

   Su tabla existente probablemente se parece a esto:

   +----+-------+---------+ | id | price | type | +----+-------+---------+ | 1 | 299 | basic | | 2 | 299 | advance | | 3 | 399 | fluent | | 4 | 0 | mattern | +----+-------+---------+

   Luego se convierte en dos tablas:

   +----+-------+ +----+------+-------------+ | id | price | | id | lang | type | +----+-------+ +----+------+-------------+ | 1 | 299 | | 1 | en | basic | | 2 | 299 | | 2 | en | advance | | 3 | 399 | | 3 | en | fluent | | 4 | 0 | | 4 | en | mattern | +----+-------+ | 1 | fr | élémentaire | | 2 | fr | avance | | 3 | fr | couramment | : : : : +----+------+-------------+

2. Otro problema con la internacionalización de una base de datos es que probablemente los estudios de los usuarios pueden diferir de EE. UU. A UK a DE ... en cada país tendrán sus niveles (que probablemente será equivalente a otro pero finalmente, diferente). ¿Y qué hay de la facturación?

   Toda localización puede ocurrir a través de un enfoque similar. En lugar de simplemente mover los campos de texto a la nueva tabla, puede mover cualquier campo localizable: solo aquellos que son comunes a todas las configuraciones regionales permanecerán en la tabla original.

Answer 2

Esta es la forma en que diseñaría la base de datos:

Visualización por DB Designer Fork

La tabla i18n solo contiene un PK, por lo que cualquier tabla solo tiene que hacer referencia a este PK para internacionalizar un campo. La translation tabla está a cargo de vincular este ID genérico con la lista correcta de traducciones.

locale.id_locale es un VARCHAR(5) para administrar las sintaxis en y en_US ISO .

currency.id_currency es un CHAR(3) para gestionar la sintaxis ISO 4217 .

Puede encontrar dos ejemplos: page y newsletter . Ambas entidades administradas necesitan internacionalizar sus campos, respectivamente title/description y subject/content .

Aquí hay una consulta de ejemplo:

select
  t_subject.tx_translation as subject,
  t_content.tx_translation as content

from newsletter n

-- join for subject
inner join translation t_subject
  on t_subject.id_i18n = n.i18n_subject

-- join for content
inner join translation t_content
  on t_content.id_i18n = n.i18n_content

inner join locale l

  -- condition for subject
  on l.id_locale = t_subject.id_locale

  -- condition for content
  and l.id_locale = t_content.id_locale

-- locale condition
where l.id_locale = ''en_GB''

  -- other conditions
  and n.id_newsletter = 1

Tenga en cuenta que este es un modelo de datos normalizado. Si tiene un gran conjunto de datos, tal vez podría pensar en desnormalizarlo para optimizar sus consultas. También puede jugar con índices para mejorar el rendimiento de las consultas (en algunos DB, las claves externas se indexan automáticamente, por ejemplo, MySQL/InnoDB ).