mysql database database-design internationalization multilingual

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



database database-design (2)

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:

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.

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?

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 ).