utf8 sirve que para online microsoft intercalacion documentación docs datos charset caracteres cambiar sql database database-design

sirve - sql server reference



¿Cuáles son las mejores prácticas para el diseño de bases de datos en varios idiomas? (5)

Encuentro que este tipo de enfoque funciona para mí:

Product ProductDetail Country ========= ================== ========= ProductId ProductDetailId CountryId - etc - ProductId CountryName CountryId Language ProductName - etc - ProductDescription - etc -

La tabla ProductDetail contiene todas las traducciones (para el nombre del producto, descripción, etc.) en los idiomas que desea admitir. Dependiendo de los requisitos de su aplicación, es posible que desee dividir la tabla Country para usar también los idiomas regionales.

¿Cuál es la mejor manera de crear una base de datos en varios idiomas? Crear una tabla localizada para cada tabla hace que el diseño y las consultas sean complejos, en otro caso agregar una columna para cada idioma es simple pero no dinámico, ayúdame a comprender cuál es la mejor opción para las aplicaciones empresariales


Estoy usando el siguiente enfoque:

Producto

ProductID OrderID, ...

Información del producto

ProductID Título Nombre LanguageID

Idioma

LanguageID Nombre Cultura, ....


La solución de Martin es muy similar a la mía, sin embargo, ¿cómo manejarías una descripción predeterminada cuando no se encuentra la traducción deseada?

¿Eso requeriría un IFNULL () y otra declaración SELECT para cada campo?

La traducción predeterminada se almacenaría en la misma tabla, donde un indicador como "isDefault" indica si esa descripción es la descripción predeterminada en caso de que no se haya encontrado ninguna para el idioma actual.


Lo que hacemos, es crear dos tablas para cada objeto multilingüe.

Por ejemplo, la primera tabla contiene solo datos de idioma neutral (clave principal, etc.) y la segunda tabla contiene un registro por idioma, que contiene los datos localizados más el código ISO del idioma.

En algunos casos, agregamos un campo DefaultLanguage para que podamos recurrir a ese idioma si no hay datos localizados disponibles para un idioma específico.

Ejemplo:

Table "Product": ---------------- ID : int <any other language-neutral fields> Table "ProductTranslations" --------------------------- ID : int (foreign key referencing the Product) Language : varchar (e.g. "en-US", "de-CH") IsDefault : bit ProductDescription : nvarchar <any other localized data>

Con este enfoque, puede manejar tantos idiomas como sea necesario (sin tener que agregar campos adicionales para cada idioma nuevo).

Actualización (14-12-2014): mire esta respuesta para obtener información adicional sobre la implementación utilizada para cargar datos multilingües en una aplicación.


Recomiendo la respuesta publicada por Martin.

Pero parece preocupado porque sus consultas se vuelven demasiado complejas:

Crear una tabla localizada para cada tabla es diseñar y consultar complejos ...

Entonces, podrías estar pensando que en lugar de escribir consultas simples como esta:

SELECT price, name, description FROM Products WHERE price < 100

... tendrías que empezar a escribir consultas como esa:

SELECT p.price, pt.name, pt.description FROM Products p JOIN ProductTranslations pt ON (p.id = pt.id AND pt.lang = "en") WHERE price < 100

No es una perspectiva muy bonita.

Pero en lugar de hacerlo manualmente, debe desarrollar su propia clase de acceso a la base de datos, que pre-analiza el SQL que contiene su marcado de localización especial y lo convierte en el SQL real que deberá enviar a la base de datos.

Usar ese sistema podría verse más o menos así:

db.setLocale("en"); db.query("SELECT p.price, _(p.name), _(p.description) FROM _(Products p) WHERE price < 100");

Y estoy seguro de que puedes hacerlo aún mejor.

La clave es tener sus tablas y campos nombrados de manera uniforme.