Respuesta

11

Primero asegúrese de que el database locale puede manejar diferentes idiomas. Use una codificación de servidor UTF-8. Opcionalmente establezca LC_COLLATE = 'C' para que esté en terreno neutral o use una intercalación para su primer idioma para tener un orden de clasificación predeterminado. Comience leyendo el capítulo Collation Support en el manual.

Le sugiero encarecidamente que utilice la última versión de PostgreSQL (9.1 en el momento de la redacción) porque tiene una compatibilidad de intercalación superior.

En cuanto a estructura de la tabla: mantenlo simple. Parece que hay un número bajo y fijo de idiomas con los que lidiar. Simplemente podría tener una columna para cada idioma:

CREATE TABLE txt (
    txt_id serial PRIMARY KEY 
,txt text NOT NULL -- master language NOT NULL? 
,txt_fr text -- others can be NULL? 
,txt_es text 
,txt_de text 
); 

Esto es bastante efectivo, incluso con muchos idiomas. NULL storage is very cheap.
Si tiene que lidiar con un número variable de idiomas, una tabla separada podría ser la mejor solución. Esta solución se supone que tiene un "lenguaje principal", donde la cadena está siempre presente:

CREATE TABLE txt (
    txt_id serial PRIMARY KEY 
,txt text NOT NULL -- master language NOT NULL? 
); 

CREATE TABLE lang (
    lang_abbr text PRIMARY KEY -- de, es, fr, ... 
,lang  text NOT NULL 
,note  text 
); 

O, si una (de dos letras) abreviatura es suficiente, basta con crear una enum type para identificar el idioma.

CREATE TABLE txt_trans (
    txt_id int REFERENCES txt(txt_id) ON UPDATE CASCADE ON DELETE CASCADE 
,lang_abbr text REFERENCES lang(lang_abbr) ON UPDATE CASCADE 
,txt  text NOT NULL -- master language NOT NULL? 
,CONSTRAINT txt_trans_pkey PRIMARY KEY (txt_id, lang_abbr) 
); 

No el tratamiento de la lengua maestro especial y manteniendo todas las variantes de idioma en la misma tabla puede hacer que el manejo más simple en su aplicación. Pero realmente depende de tus requisitos.

+0

¿Qué opina sobre el uso del tipo de datos JSON para almacenar los valores adicionales, codificados por el código de configuración regional? –

+0

@JeremyBaker: El tipo de datos 'json' es una buena solución para un grupo grande de atributos posiblemente variables. No tanto por una mano llena de atributos bien conocidos (como en este ejemplo). Depende de la imagen completa. Cuando se hizo esta pregunta, Postgres 9.2 tenía un soporte json muy básico. Las cosas han mejorado mucho desde entonces, al agregar 'jsonb' ... –

Cuestiones relacionadas