Un approccio al design db multilingue

Question

Un approccio al design db multilingue

Naviga le tue risposte

#1 da (2 voti)

2

Il mio capo sta pianificando un nuovo db e desidera supportare i dati multilingue in questo modo:

LocalizedDescs (Guid / LanguageGuid è la chiave primaria)

Cluster
Guid
LanguageGuid
Desc

categorie merceologiche

Cluster
Guid
(...)

Prodotti

Cluster
Guid
CategoryGuid
DetailedDescGuid
(...)

Il modo in cui funziona è che ogni tabella ha un campo Guid , usato come chiave primaria. Il campo LocalizedDesc della tabella Guid , a sua volta, corrisponde a qualsiasi guida utilizzata nelle tabelle in tutto il db, rendendolo una tabella genitore per ogni tabella nel sistema.

In rari casi in cui un record di tabella ha bisogno di un'altra risorsa localizzata, nella tabella viene utilizzato un campo aggiuntivo che punta anche a un record LocalizedDesc . Ad esempio, la tabella Products ha una DetailedDescGuid che intende contenere una descrizione estesa e più lunga di un prodotto. In questo modo abbiamo sia una descrizione riassuntiva che una descrizione dettagliata, entrambe le quali possono essere localizzate in diverse lingue.

Originariamente, dovevamo avere un campo LocalizedDescGuid in ogni tabella che necessitava di una descrizione. Ma il mio capo afferma che gli indici db saranno più piccoli se lo facciamo nell'altro modo.

Dal punto di vista del design, qual è la soluzione di questa soluzione? Era meglio quando usava un campo aggiuntivo in ogni tavolo? O stiamo sbagliando tutto questo?

design architecture database-design

posta Crono 18.06.2015 - 15:29

fonte

1 risposta

Leggi altre domande sui tag design architecture database-design

Implementazione di una serie di azioni indipendenti disparate ma con accessibilità comune Come fornire una buona esperienza utente con un'app più lenta

score 2 · Accepted Answer

Suggerirei la seguente struttura a causa delle mie esperienze in alcune altre applicazioni.

Prima di tutto vorrei creare una tabella lingua :

language_id (PK)
iso_country_code
iso_language_code
codepage
translation_id (FK)

Il language_id rappresenterebbe la chiave primaria. Ogni lingua disponibile viene aggiunta a questa tabella. iso_country_code può contenere il codice ISO del Paese (GB - Gran Bretagna, Germania - Germania, ...). iso_language_code può essere utilizzato per coprire lingue diverse localizzate (ad es. en_US, en_GB, ...) codepage è la codepage che verrà inviata. translation_id in più su questo più tardi.

La seconda cosa dovrebbe essere una tabella traduzione . La tabella di traduzione dovrebbe trattenere tutte le traduzioni per ogni termine traducibile.

translation_id PK
language_id PK (FK -> language)
term

La tabella consiste in una chiave primaria combinata su translation_id e language_id che impediscono il doppio inserimento. language_id farà riferimento alla tabella della lingua. term stesso sarà solo il termine tradotto (ad es. Tabella in tedesco - > Tabelle)

La prossima cosa succederà su ogni tavolo che contiene oggetti traducibili. Ad esempio una tabella che contiene i tuoi prodotti, ad esempio denominati prodotti .

product_id PK
product_information
product_price
...
translation_id (FK)

È necessario solo translation_id . Si riferirà alla tabella traduzione e recupererà la traduzione corretta. L'applicazione può dare o la sessione utente può essere unita alla dichiarazione per filtrare la lingua corretta per l'utente che ha effettuato l'accesso.

L'altra cosa positiva di questa soluzione è che se hai più traduzioni in tabelle diverse che significano tutte la stessa cosa ma in un contesto diverso e tutte possono avere lo stesso translation_id , possono già condividere lo stesso translation_id che ridurrà il peso dei dati e migliorerà la traduzione.

Speriamo che questo ti dia un buon suggerimento e ti aiuti a migliorare la tua soluzione.