Newsgroup: it.comp.software.database
Titolo: progettare dabase multilingua ....

salve dovrei realizzare un database multilingua un sitema (un portale web)
mi chiedevo le news glil articoli mi potete dare qualche aiuto su come 
strutturare le tabelle in modo che
possa funzionare con un numero definito(ma estendibile) di lingue  ?
grazie ciao


aggiungere un attributo lingua in ogni tabella che ti interessa 
internazionalizzare?

 ha scritto nel messaggio 
news:Cbjhe.1382548$35.51...@news4.tin.it...

[mysql]
CREATE TABLE articoli (
articolo_id tinyint(2) NOT NULL auto_increment,
linguaggio_id tinyint(2) NOT NULL default '0',
articolo_nome varchar(10) NOT NULL default '',
articolo_descrizione varchar(25) NOT NULL default '',
PRIMARY KEY (articolo_id)
)
cosě ? per ogni entitň news etc protrebbe andare ? 

 così ? per ogni entitò news etc protrebbe andare ? 
no direi proprio di no.
Nello specifico caso il motivo del no è che ti perdi la possibilità di 
definire una primary key unica su una entità che sembra principale(anche 
se cambia la descrizione l'articolo rimane quello).
In questo specifico caso ti suggerirei una soluzione del genere
Tabella articoli
ID Primary key
articolo_nome
*tutti gli attributi che non ha senso 
internazionalizzare(produttore,intermediario,tipologia,ecc ecc)
Tabella articoli_lang
ID
Lingua
Attributo
Valore
Potresti avere una situazione del genere
Articolo
123, ProdottoA,ProduttoreA,Tipo
Articolo_lang
123,"IT","Descrizione","Questa è la descrizione del prodotto A"
123,"EN","Descrizione","This is the description ...."

 ha scritto nel messaggio 
news:JGlhe.895629$b5.39...@news3.tin.it...

mi son perso non capisco che vantaggio ha la tua soluzione potresti 
spiegarmi  ?
un ultima cosa
se vorrei avere un legame 1-1 fra ad' esempio una news e le varie lingue del 
tipo
vedo la news e la voglio vedere in in inglese spagnolo etc
coem dovrei strutturare il db  ?
grazie ciao

 ha scritto nel messaggio 
news:JGlhe.895629$b5.39...@news3.tin.it...

ho riletto con calma mi spiego meglio:
Dunque alcune cose non mi sono chiare:
perchè hai scritto due volte "Descrizione" hai forse sbagliato la seconda 
volta dovevi scrivere "Descriptio" ?
Poi in pratica per ogni entità
Articoli,News,etc. dovrei avere una struttura del genere?
es:
News , News_lag
Newslettter , Newsletter_lang e via dicendo ?
Un'altra cosa scusa se rompo :)
diciamo che io vorrei fare in modo che ogni (faccio un esempio sulle news ma 
potrebbe rifersi agli articoli etc.) news si possa leggere in diverse lingue
... termino mi sono risposto da solo .-)
aspetto risp. per le altre domande
grazie ancora ciao

 ... termino mi sono risposto da solo .-)
basta lavorare con le query di estrazione :-); in teoria per il 
monolingua basta settare una variabile "globale" con il codice della 
lingua selezionata al momento della scelta iniziale.


L'idea che hai avuto sulla chive e prodotti e tabella mi sembra molto buona 
perchè così come dici appunto tu
il prodotto in se stesso resta univoco.
Non mi va tanto il campo attributo (descrizione)
Contando che devo gestire un portale con questo database, provo una 
soluzione simile alla tua ma  un pò modificata eccola:
//identica alla tua
Tabella articoli
ID Primary key
articolo_nome
*tutti gli attributi che non ha senso
internazionalizzare(produttore,intermediario,tipologia,ecc ecc)
Tabella articoli_lang
ID
Lingua
CampodaInternazionalizzare1
CampodaInternazionalizzare2
CampodaInternazionalizzare3
CampodaInternazionalizzare4
etch.
fare una query del genere
select * from  articoli,articoli_lang where
articoli.id
 = 
articoli_lang.id
and Lingua = "IT"
secondo te con questa soluzione che vantaggi  / svantaggi potrei avere ?
La tua l'ho cambiata perchè nel caso che io dovrei modificare un campo si 
creerebbero una serie di modifiche a catena anche sul
codice (se descrizione diventa qualche altra cosa....)
Cosa ne pensi potrebbe andare pensa che devo gestire cose del tipo
news,rubriche, newsletter, eventi , file di download (i classici contenuti 
di un portale web)
aspetto grazie ancora....

 di un portale web)
non so che tipo di struttura generale hai in mente; non ti posso essere
di aiuto su questo punto.
ciao
Matteo

 ha scritto nel messaggio 
news:1116226453.3...@g47g2000cwa.googlegroups.com...



trlasciando il discorso modifiche etc. se puoi mi spiegheresti perchè la mia 
non  è normalizzata ? quelli sono attributi della tabella xxx_lan cosa non 
quadra ?
e poi scusa l'ignoranza ma questa

 and lang = "IT"
non è una query con condizione ? 

yag ha scritto:

Hai n campi uguali (la cui funzione è la stessa) per n lingue.
Che succede se aggiungi una lingua?
Che succede se decidi di eliminare una lingua?
Che succede se hai articoli differenziati per nazione (o lingua)?
Poi, se vuoi un consiglio non usare le select * .... sono comode ma se 
aggiungi un campo alla tabella il tuo programma si va a far friggere 
(oltre che avere una leggibilità notevolmente inferiore) :-)
Ciao
Gianni

Chiedo venia per l'orribile quoting!!

 Chiedo venia per l'orribile quoting!!
Stavi per essere cazziato ;) :D
-- 
Borland C++ Builder Mailing List:
http://tux.linuxtime.it/mailman/listinfo/bcb-it


Non l'ho capita :-)
Non capisco se sono vantaggi o svantaggi

 Non l'ho capita :-)
Se usi le select * il set di campi che ottieni varia secondo il numero 
di campi presenti nella tabella. Prendiamo un esempio in php:
Codice 1:
$risultato = mysql_query("select * from cliente");
Codice2:
$sql = "
        SELECT
	    id,
             nome,
             cognome,
             indirizzo
	FROM
             cliente
        ";
$risultato = mysql_query($sql);
1) Se aggiungi un campo nella tabella cliente, il codice1 da problemi se 
non hai usato un buon metodo di recupero dei valori del record, il 
codice2 funziona comunque (è solo un banale esempio ma una problematica 
che puoi riscontrare anche in altri linguaggi)
2) se aggiungi un capo alla tabella a metà, il codice1 darà sicuramente 
errore nel recupero dei dati (in quanto il set $risultato varia). Il 
codice2 funziona comunque
3) Se cambi l'ordine di un solo campo della tabella il codice1 va in 
palla (In quanto varia l'ordine dei campi in $risultato). Il codice2 
funziona comunque.
4) Nel codice1 non si capisce una mazza che campi andiamo a recuperare. 
Il codice 2 è decisamente più leggibile e senza andare a vedere la 
tabella sò esattamente i campi che stò recuperanto (quindi trovo più 
facilmente gli eventuali errori anche a distanza di tempo)
5) se, in seguito, devi fare una join con altra tabella, trasformare il 
codice2 è semplice, il codice1 necessita di scrivere comunque i nomi dei 
campi da recuperare (quindi devi andare a rivederteli)
6) se fai altre query nel codice, con join, non fai altro che fare copia 
incolla dei campi con le query già scritte
Adesso prova tu ad elencarmi i vantaggi dell' * ;-)
Ciao
Gianni

 
fiuuuu!!! che culo,  mi son salvato appena in tempo :D
Ciao
Gianni


Be comunque grazie, per quanto riguarda il php non ho problemi in quanto per 
estrarre i dati uso un mio framework ad oggetti che "wrappa" le funzioni 
base php
:)

 :)
Quando poi magari farai un porting su un tuo progetto senza framework o 
su un altro linguaggio, oppure semplicemente quando tornerai sul codice 
dopo anni o passerai il codice a qualcuno, saranno dolori. ;-)
P.S.
A me non importa come tu scrivi il codice (non mi viene in tasca da 
questo). Io lavoro con altri 4 programmatori e quando leggo il codice e 
le query dei miei colleghi le capisco anche senza andare a vedere la 
struttura del database.... non oso pensare se usassimo le select *...... 
brrrr :-)
Ciao
Gianni

 ha scritto nel 
messaggio news:%N9ie.906884$b5.39...@news3.tin.it...

Heheheh :-) 

 > >> ho riletto con calma mi spiego
io farei una cosa del genere
una tabella per ogni lingua
poi (identiche) questo per evitare di avre una tabella molto grossa
(3.000.000 record)
id, id_prodotto, descrizione
pero te la puoi evitare se e' piccolo usando un flag
id, id_prodotto, descrizione, numerico
ovviamente se non lo trova puoi fare una preferenza di lingua da mostrare la
descrizione
e come prioritario la lingua dell'utente numerico
1 = ita
2 = eng
3 = esp
jp
ricordati di permettere all'utente di selezionare la lingua che preferisce
(a volte e' piu
chiaro l'inglese) o se non c'e l'articolo lo puo leggere in altra lingua,

 ha scritto nel messaggio 
news:Boqie.103365$IN.17...@twister2.libero.it...

Ok