Newsgroup: it.comp.software.database
Titolo: disegno db per sito multilingua

per un sito multilingua abbiamo deciso si seguire il seguente schema, 
replicare le tabelle della lingua di default (es: en) ponendo un suffisso 
con la lingua di turno, quindi:
tabella_en
tabella_fr
tabella_it
etc
dove tabella _fr e _it hanno una chiave esterna verso _en
ci stiamo chiedendo quale è la migliore soluzione per gestire i campi che 
non hanno bisogno di traduzione (es: il path ad una img)
soluzione 1: tenere tali campi nella sola tabella_en ed interrogarla in 
join con la tabella della lingua corrente
soluzione 2: tenere tali campi in una ulteriore tabella chiamata ad 
esempio tabella_intraducibili (poi scegliereemo un nome migliore :))
soluzione 3: replicare tali campi in tutte le tabelle.
da notare : il db avrà poche insert e molte (si spera) select.
il db sarà molto piccolo, si parla di record nell'ordine delle centinaia.
quindi cosa preferire?
le sol 1 e 2 richiedono una join che quindi rallenterebbe le select
la sol 3 ha campi ridondanti che in linea teorica non sono una bella cosa 
a livello di progetto del db.
voi che ne pensate?

 voi che ne pensate?
Secondo me la 2 è la più indicata, concettualmente stai tenendo degli 
elementi indipendenti dalla lingua in una struttura pensata per degli 
elementi multilingua.
Potresti anche condensare tutto in due tabelle, elementi indipendenti 
dalla lingua e elementi dipendenti con un campo "language" che valorizzi 
con "en", "fr" e "it" in questo modo non hai il problema di eseguire la 
join come hai evidenziato.

 wrote in news:i99hds$j3t$
1...@tdi.cu.mi.it
:

cosi' per aggiungere una lingua dovete modificare il database.
hum...
imo una scelta decisamente poco felice.
io voto per una sola tabella con il campo 'lingua'; data una lingua, con 
due select al massimo, senza join, ottieni il risultato
declare @risultato
select @risultato = stringa
from tabella
where idstringa=@id and lingua=@lingua
if @risultato is null
    	select @risultato = stringa
    	from tabella
    	where idstringa=@id and lingua='lingua di default'
if @risultato is null
    	raiserror
dove @id e @lingua sono i due parametri dell'interrogazione (che stringa 
vuoi e in che lingua)
- se devi aggiungere una lingua, non devi scardinare il database
con la tua soluzione, per ogni nuova lingua devi creare una nuova 
tabella, creare le nuove chiavi e aggiornare tutte le select esistenti.
peggio ancora: non devi aggiornare le select perche' usi sql dinamico.
- se devi togliere una lingua, non devi scardinare il database E il 
software
con la tua soluzione, per eliminare una lingua dal db devi cestinare 
tutte le tabelle dopo aver eliminato eventuali chiavi esterne e sperare 
di non aver messo da qualche parte nel codice il nome di quelle tabelle 
che hai appena distrutto.
con tabella singola e il campo 'lingua' la struttura resta invariata e 
per eliminare la lingua basta fare:
delete from tabella where lingua = 'id della lingua da eliminare'
- se devi correggere una stringa sai esattamente dove cercarla
col tuo sistema, se trovi una stringa errata, la devi cercare in tutte le 
tabelle, perche' potrebbe esserci lo stesso errore in tutte.
per esempio, hai la dicitura 'slava file' che non e' localizzata quindi 
e' identica in tutte le tabelle; devi verificare in tutte le tabelle.
se hai una sola tabella la tringa puo' essere solo li' e la correggi con 
un update:
update tabella 
set stringa='salva file'
where idstringa='salva' and dicitura='slava file'
-- 
Paolo opg
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--

 imo una scelta decisamente poco felice.
infatti forse cambiamo direzione

tutto corretto, ho trovato una soluzione che mi piace molto su 
codeproject:
http://www.codeproject.com/KB/aspnet/
LocalizedSamplePart2.aspx#databasedesign
credo che adottero' quella (che è simile a quella che proponete te e 
andrea)
grazie a tutti, scusate per le corbellerie, ma era la prima volta che mi 
trovavo a dover progettare un multilingua :)

 voi che ne pensate?
Ho già fatto db multilingua.
La soluzione che ho trovato migliore è:
tabella base con tutti i campi indipendenti dalla lingua.
Tabella localizzata con tutte le lingue che ti servono in relazione
uno a molti.
La struttura rimane la stessa anche con 1000 lingue.



si, infatti è proprio quella proposta nell'articolo che ho linkato

 esempio tabella_intraducibili (poi scegliereemo un nome migliore :))
Io adotto questa.
Tabella lingue (con un ID)
Tabella traduzioni con id della lingua e id del campo (in realta' ho piu' d'una
tabella "detail" con varie tabelle "master")
C'e' una lingua "di default" (configurabile dall'amministratore del sito).
Ovviamente in quella lingua deve esistere ogni messaggio.
Una funzione apposita si occupa di recuperare la traduzione di un "testo"
ricevendo un identificativo del testo e uno della lingua. Se la funzione trova
il messaggio in quella lingua ok, se non lo trova cerca lo stesso messaggio
nella lingua "di default".
Ciao,
luigi
-- 
/
+--[Luigi Rosa]--
\
If you push the "extra ice" button on the soft drink vending machine,
you won't get any ice.
If you push the "no ice" button, you'll get ice, but no cup.

 Ovviamente in quella lingua deve esistere ogni messaggio.
E aggiungo: se metti nella tabella delle lingue anche il codice a sue lettere
ISO, puoi proporre anche a chi ti viene a visitare una lingua di default in base
a quella presentata dal browser andando a leggere l'header Accept-Language e
confrontandolo con i valori in database.
Ciao,
luigi
-- 
/
+--[Luigi Rosa]--
\
The phonograph has no commercial value at all.
       --Thomas Edison, circa 1880

 si, infatti è proprio quella proposta nell'articolo che ho linkato
Mi permetto di aggiungere: occhio a quegli attributi che a prima vista
non sembrano avere attinenza con la nazionalita' e, poi, in seconda
battuta, ce la hanno eccome. Es. nel campo dei prodotti: prezzi,
aderenza a standard, accessori.