Progettazione di uno schema di database localizzato

Question

Eventuali duplicati:
Schema for a multilanguage database

Sto lavorando su un'applicazione web che ho in programma di rendere disponibile in più lingue. Mentre progetto il database, sto andando avanti e indietro tra due diversi modi per archiviare descrizioni localizzate e quant'altro nel database.

prima opzione è il ben noto table_name, opzione type table_name_ml:

TABLE Category (
    ID int, 
    ParentID int, 
    Name varchar(50), 
    Description varchar(255) 
) 

TABLE Category_ML (
    ID int, 
    CategoryID int, 
    LocaleID int, 
    Name varchar(50), 
    Description varchar(255) 
) 

La seconda opzione sarebbe quella di non memorizzare il testo nelle tabelle di base a tutti, ma memorizza un token che potrebbe essere utilizzato di ricercare il testo effettivo localizzato altrove, in questo modo:

TABLE Category (
    ID int, 
    ParentID int, 
    NameToken varchar(50), 
    DescriptionToken varchar(50), 
) 

// Tables in a separate content management type system 
TABLE Content (
    ID int, 
    Token varchar(50) 
) 

TABLE Translation (
    ID int 
    ContentID int, 
    LocaleID int, 
    Value text 
) 

l'idea è che il contenuto e traduzione tabelle sarebbero contenere il testo localizzato per molti soggetti diversi nel database. Il livello di servizio restituirebbe gli oggetti di base con solo i token e il livello di visualizzazione cercherebbe i valori di testo effettivi usando le tabelle Contenuto/Traduzione, che sarebbero pesantemente memorizzate nella cache. Le tabelle Contenuto/Traduzione verrebbero utilizzate anche per memorizzare altro tipo di contenuto CMS (testo statico su pagine Web, ecc.)

Mi piace la prima opzione perché è provata e vera, ma la seconda opzione sembra avere così tante altre vantaggi:

1. Tutto il mio testo/contenuto localizzato è in un posto (rende più facile la traduzione).
2. Il livello di servizio non ha realmente bisogno di preoccuparsi delle impostazioni locali.
3. Semplifica le query non dovendo partecipare a un gruppo di tabelle di tipi ML.

Dal momento che non ho mai visto un progetto come questo prima, presumo che mi manchi qualcosa. Qualche buona ragione per non progettarlo in questo modo? O forse c'è un'opzione migliore a cui non ho pensato?

Answer 1

Prima dirò che non ho avuto a che fare con la localizzazione prima, quindi questa è solo la mia opinione e non basata sull'esperienza.

Mi piace la tua seconda opzione. Per quanto riguarda il DB va .. i suoi dati e un modo per accedere/manipolare i dati. In questo caso tutti i dati sono lì e lo leggerete per lo più e avrete un buon modo per arrivarci. Puoi rispondere allo stesso problema in entrambi gli scenari. Preferirei la seconda opzione perché riduce i matti tavoli ovunque. Stai tenendo un tavolo per lo scopo specifico della traduzione. Puoi riutilizzarlo (non creare più tabelle solo per gli aggiornamenti più tardi) e mantenere l'integrità. Potresti anche riutilizzare i nomi se ha senso da qualche parte. Come se tu avessi "Mantequilla" come Categoria e come Preferito da qualche altra parte.

Mi piace mettere i dati correlati in una tabella quando possibile e non avere dati relativi alla "traduzione" in più posti.

L'unico posto in cui questo può fallire è se si dispone di più di un semplice nome e descrizione per qualcosa che necessita di traduzione. Forse hai nome, descrizione, codice, parola magica, soprannome sciocco, ecc. Per un oggetto. Sebbene tu possa aggirare questo aggiungendo altri NameToken in quella tabella pertinente e riutilizzando Name, ma questo è un po 'un hack.

Assicurati che il modello soddisfi tutti i tuoi bisogni e dovrebbe funzionare correttamente. Puoi sempre inserire una tabella di traduzione speciale se necessario in seguito per una tabella specifica. Ciò non sarebbe diverso dalla creazione di molti tavoli, anche se una soluzione ibrida potrebbe confondere. È meglio trovare un modo e provare ad attenervisi.

Answer 2

C'è un'opzione in più e penso che scommetto su questo!

• Separazione totale del database!

ragioni (PROS):

• Pyhsically separati localizzato banca dati
• Ponteggi (livelli di presentazione generati)
• Facile Orm

CONTRO:

• È necessario risolvere il problema UniqueId (replica)
• È necessario sincronizzare schema e non-localizzazione dei dati