Mejores prácticas para el diseño de bases de datos en varios idiomas

Para implementar soporte multilingüe en su modelo de datos, no necesita reinventar la rueda. Este artículo le mostrará las diferentes formas de hacerlo y lo ayudará a elegir la que mejor se adapte a sus necesidades.

El concepto de localización es vital para el desarrollo de una aplicación de software, particularmente cuando el alcance de esa aplicación es global. El soporte para múltiples idiomas es el principal aspecto a considerar; un diseño de base de datos que soporta una aplicación en varios idiomas le permite diversificar sus mercados objetivo y así llegar a muchos más clientes. Además, dicho diseño de base de datos podría ser parte de su estrategia a largo plazo para diseñar sistemas listos para la localización.

La clave para incorporar soporte multilingüe en su aplicación es hacerlo de una manera que no aumente drásticamente los costos de desarrollo o mantenimiento. Dado que el modelado de bases de datos es una parte inseparable del proceso de desarrollo de software, debe pensar en la mejor estrategia de diseño de modelos de datos para brindar soporte multilingüe a su aplicación.

Un modelo de datos adecuado debería permitirle modificar la aplicación o agregar una nueva funcionalidad mientras mantiene la compatibilidad con varios idiomas, sin agregar esfuerzo ni costos adicionales. También debería permitirte incorporar nuevos idiomas sin tocar la aplicación; solo necesita agregar los datos de traducción correspondientes a la base de datos.

Implementación simple frente a flexibilidad y funcionalidad

Existen diferentes enfoques para crear un diseño de base de datos para aplicaciones en varios idiomas. Cada uno tiene sus ventajas y desventajas. Los que son más fáciles de implementar ofrecen menos flexibilidad y menos funcionalidad; aquellos que ofrecen más flexibilidad y funcionalidad tienen implementaciones más complejas.

Mi consejo aquí es siempre ir por los que ofrecen más funcionalidad y flexibilidad , incluso si son más caros de implementar. A veces cometemos el error de pensar que una aplicación es demasiado pequeña, que no vale la pena implementar esquemas complejos para resolver cosas como el soporte multilenguaje. Pero eventualmente, esa aplicación crecerá y nos arrepentiremos de haber optado por el enfoque "rápido y sucio" que parecía más simple y menos costoso.

Lo ideal para implementar una funcionalidad accesoria en una aplicación, ya sea compatibilidad con varios idiomas, registro de cambios, autenticación de usuarios u otra cosa, es que esa funcionalidad tenga su propio subesquema y su lógica encapsulada en componentes reutilizables. De esta manera, tanto la funcionalidad del accesorio como su subesquema se pueden incorporar a cualquier nueva aplicación con el mínimo esfuerzo.

Una herramienta inteligente de diseño de bases de datos y modelado de datos como Vertabelo es de gran ayuda para la gestión eficiente de sus esquemas y subesquemas. Además, consulte estos consejos para un mejor diseño de la base de datos y asegúrese de seguirlos todos. Antes de comenzar a dibujar su diagrama ER, le sugiero que considere esta serie esencial de consejos de modelado de bases de datos.

Algunas soluciones de diseño de bases de datos multilingües atractivas (pero desaconsejables)

Más fácil, pero menos recomendado

Comencemos con la forma menos recomendada pero más fácil de implementar una base de datos de aplicaciones en varios idiomas. Te permite resolver rápidamente la necesidad de soportar una aplicación multilenguaje, pero te traerá problemas cuando la aplicación crezca en funcionalidad o en cobertura geográfica.

Esta estrategia simple consiste en agregar una columna adicional por cada columna de texto que necesita traducción y por cada idioma al que se deben traducir los textos.

Por ejemplo, en Movies tabla a continuación, hay un OriginalTitle campo. Se agrega una columna de título adicional para cada idioma a traducir:

La aplicación debe obtener los datos de descripción de la columna correspondiente al idioma seleccionado por el usuario. Cuando necesite agregar un nuevo idioma, debe agregar una columna adicional a la tabla para contener los textos traducidos al nuevo idioma. También debe adaptar la aplicación para reconocer el idioma y las columnas agregados.

Esta solución no requiere JOIN complicados para obtener los textos traducidos, ni registros duplicados, solo la replicación de columnas de contenido de texto. Pero su aplicabilidad está limitada a situaciones en las que solo se necesita traducir unas pocas tablas.

Por ejemplo, suponga que tiene un Products tabla y un Processes mesa. Cada uno de ellos tiene un campo Descripción que necesita traducción; parece bastante fácil, ¿verdad? Pero si toda la aplicación (incluidas todas sus opciones de menú, mensajes de error, etc.) necesita ser multilingüe, esta solución no es aplicable.

Más versátil, pero tampoco recomendable

Siguiendo con la idea de mantener las traducciones dentro de una misma tabla, una alternativa a la anterior es ampliar los campos de texto. Esto nos permitiría almacenar todas las traducciones en el mismo campo, organizándolas en una estructura de datos (por ejemplo, un documento XML o un objeto JSON). A continuación tenemos un ejemplo:

Esta opción no requiere columnas adicionales, pero agrega complejidad. Las consultas de datos ahora deben poder procesar e interpretar correctamente la estructura de datos utilizada para el soporte multilingüe. Por ejemplo, si se usa JSON o XML para almacenar traducciones, las consultas de SQL deben usar una versión de SQL que admita el tipo de datos elegido.

El siguiente comando SQL utiliza MS SQL Server OPENJSON() función para utilizar el contenido de las Translations campo como una tabla subordinada:

SELECT
	m.MovieId,
	m.OriginalTitle,
	t.TranslatedTitle
FROM
	Movies AS m
	CROSS APPLY OPENJSON(m.Translations)
		WITH (
			language char(2) '$.language',
		TranslatedTitle varchar(100) '$.title’
		) AS t
WHERE t.language = 'fr';

Dado que no hay funciones u operadores para manipular datos con formato JSON o XML en SQL estándar, se ve obligado a escribir sus consultas para un RDBMS en particular si desea utilizar esta técnica para almacenar textos traducidos. Por ejemplo, MySQL no admite la consulta anterior. Si necesita leer los datos JSON en las Movies table con MySQL, escribirías esta consulta:

SELECT
	m.MovieId,
	m.OriginalTitle,
	JSON_EXTRACT(m.Translations, '$.title') AS TranslatedTitle
FROM Movies AS m
WHERE JSON_EXTRACT(m.Translations. '$.language') = 'fr';

Almacenamiento de texto traducido en diferentes registros

También puede optar por utilizar registros diferentes para cada idioma. Sin embargo, debes resignarte a perder la normalización:los mismos datos se repiten en varios registros, en los que solo varía la traducción.

Con esta opción, puede crear vistas de cada tabla que devuelvan solo las filas en un idioma determinado:

CREATE VIEW Movies_en AS
SELECT MovieId, Title
FROM Movies
WHERE LanguageId = 'en';

CREATE VIEW Movies_sp as
SELECT MovieId, Title
FROM Movies
WHERE LanguageId = 'sp';

Luego, para consultar la tabla, puede usar una vista diferente según el idioma de traducción de destino. Pero se pierde la normalización del modelo y el mantenimiento de la tabla es innecesariamente complejo.

Almacenamiento de texto traducido en tablas separadas

Una forma de almacenar los textos traducidos sin romper el modelo relacional es tener una tabla de detalles para cada tabla que contiene los textos a traducir. La tabla subordinada que contiene las traducciones debe tener los mismos campos clave que la tabla madre, más un campo que indique el idioma de traducción.

Una tabla subordinada con traducciones debe tener los mismos campos clave que la tabla principal, más un campo que indique el idioma de traducción.

Esta opción permite incorporar nuevos idiomas sin alterar la estructura de la tabla. No requiere generar información redundante ni romper la normalización del modelo.

El inconveniente de esta opción es que requiere la creación de una tabla subordinada para cada tabla que almacena datos textuales que requieren traducción. Sin embargo, la idea de almacenar las traducciones en tablas relacionadas nos acerca a la forma más recomendable de diseñar una base de datos multilenguaje.

La solución universal:un subesquema de traducción

Para que una aplicación y su base de datos sean verdaderamente multilingües, todos los textos deben tener una traducción en cada idioma admitido, no solo los datos de texto en una tabla en particular. Esto se logra con un subesquema de traducción donde se almacenan todos los datos con contenido textual que pueden llegar a los ojos del usuario.

En las aplicaciones web destinadas a su uso en diferentes idiomas, un subesquema de traducción es una necesidad, no una opción. Cualquier otra cosa dará lugar a complejidades que imposibilitarán el correcto mantenimiento de la aplicación.

La clave para mantener las traducciones en un esquema separado es mantener un catálogo indexado con todos los textos que necesitan traducción, ya sean descripciones de entidades, mensajes de error u opciones de menú. La idea es que ningún texto que pueda llegar a los ojos del usuario se almacene en ninguna tabla fuera de este subesquema.

Una forma de organizar el catálogo de traducciones es utilizar tres tablas:

• Una tabla maestra de idiomas.
• Una tabla de textos en el idioma original.
• Una tabla de textos traducidos.

Esquema para un catálogo de traducción universal.

En la tabla maestra de idiomas, simplemente insertamos un registro para cada idioma admitido por el modelo de datos. Cada uno tiene un código de identificación y un nombre:

La tabla de texto registra todos los textos que requieren traducción. Cada registro tiene una identificación arbitraria, el texto original y la identificación del idioma original.

En el TextContent tabla, el texto original y el ID del idioma original no son estrictamente necesarios. Pero simplifican las consultas que no requieren traducción. Por ejemplo, al realizar consultas de análisis estadístico o de control de gestión (que normalmente solo están disponibles para usuarios que entienden el idioma original), las consultas se pueden simplificar utilizando los textos predeterminados (no traducidos).

Los textos originales también son útiles para quienes tienen que llenar la tabla de textos traducidos. La entrada de datos de traducción se puede realizar mediante una miniaplicación que muestra el texto original y las traducciones en todos los idiomas disponibles. También es posible generar información para el subesquema de traducción a través de un proceso automático utilizando una API de traducción.

Enlace con el esquema principal

En el esquema principal de la aplicación, las columnas con valores de texto que necesitan traducción se reemplazan por ID que apuntan a la tabla de textos traducidos:

El esquema principal está vinculado al esquema de traducción a través de tablas con textos que necesitan traducción.

Puede dejar el campo de texto original en algunas de las tablas del esquema principal para facilitar consultas donde no se requiere traducción, aunque esto genera información redundante. Por ejemplo, podríamos mantener el ProductDescription campo en Products table para facilitar consultas estadísticas o para poblar las dimensiones de un almacén de datos, dejando de lado el subesquema de traducción cuando no se necesita.

• Diseño de base de datos en varios idiomas:hágalo una vez y hágalo bien

Hemos visto varias alternativas para crear un diseño de base de datos multilingüe. Algunos son más fáciles y rápidos de implementar. La última solución es un poco más compleja, pero le brinda mucha más flexibilidad. También le ahorrará problemas cuando llegue el momento de mantener la aplicación y la base de datos. Así, a la larga, será mucho menos costoso.

A veces, el camino más corto en el diseño de bases de datos lo tienta a creer que ahorrará tiempo y esfuerzo. Pero cuando lo eliges, estás pasando por alto el hecho de que probablemente tendrás que bajarlo varias veces. Si ignora las mejores prácticas para el diseño de bases de datos multilingües, probablemente terminará haciendo el mismo trabajo una y otra vez.