Struttura DB [Multilingua]

scura

Struttura DB [Multilingua]

Salve a tutti

ho un dubbio ricorrente vorrei fare chiarezza una volta per tutte

Si tratta della struttura di un db per sito multilingua

Secondo voi meglio un DB di questo tipo

es. Tbl_nomi

ID - contatore
nome_lingua1 - testo
nome_lingua2 - testo

ecc...

oppure

ID - contatore
Nome - testo
Lingua - numerico

ecc...

???

paocavo

Ciao scura,
entrambe le possibilità sono fattibili dipende da cosa devi fare. il primo caso è quello + statico (e meno normalizzato). Va bene se sei arcisicura che in futuro non userai più di due lingue (a meno che non aggiungerai una colonna per ogni nuova lingua ma questo sarà sconveniente in quanto la modifica della struttura del db comporterà modifiche sostanziali al codice).

Il secondo caso è più flessibile e normalizzato in quanto la struttura della tabella rimane la stessa anche all'aumentare del numero di lingue che il tuo sito supporterà. Le modiche al codice saranno minime ed aggiungerai solo un record nella tabella di lookup "Lingue" del tipo:

Table Language:

id_lang: (numerico - chiave primaria - not null)
lang_name: (testo)

la chiave primaria sarà poi relazionata al campo numerico della tabella che hai proposto come seconda soluzione.

legolas

@scura said:

Salve a tutti

ID - contatore
Nome - testo
Lingua - numerico

???

Io direi questa e come ha detto paocavo ti crei una tabella i lookup "Lingue", e inserisci tutte le lingue che vuoi senza avere tanti problemi di codice

scura

Pensavo la stessa cosa, ma volevo un parere

ora vi chiedo un'altra cosa a riguardo vi faccio capire cosa alimentava i miei dubbi

Utilizzando il secondo metodo

supponiamo di dover fare un e-commerce in cui ogni articolo ha la traduzione per es. di breve_descrizione e descrizione_dettagliata del prodotto più vari campi tra cui prendiamo per fare l'es. il campo quantita_magazzino

id - contatore
breve_descrizione - memo
descrizione_dettagliata - memo
quantita_magazzino - numerico
lingua_ID - numerico
traduzione_di_ID - numerico

Ho aggiunto il campo traduzione_di_ID per memorizzare l'id della lingua diciamo di default poichè se l' utente_A acquista 5 articoli del prodotto_X dovrò sottrarre 5 nel campo quantita_magazzino a tutti i record corrispondenti nelle varie lingue

Se invece avessi usato la prima struttura ciò non sarebbe stato necessario

Entrambe le soluzioni sono ovviamente applicabili
ma quale usereste voi per una situazione di questo genere ?
Restate sempre dell'idea che è preferibile la seconda ?

scura

@scura said:

Ho aggiunto il campo traduzione_di_ID per memorizzare l'id della lingua diciamo di default ?

mi sono espressa male
il campo traduzione_di_ID memorizza l'id del record (non della lingua) con lingua = alla lingua di default

paocavo

Il concetto fondamentale è "capire" che cosa è in realtà un "articolo". un articolo è un oggetto (generico) identificato da un codice univoco è una giagenza. Altre informazioni tipo nome, descrizioni, prezzi sono attributi multivalore e pertanto, in fase di normalizzazione dal modello entità-relazioni (concettuale) al modello relazionale (logico) vanno a espandersi su altre tabelle. Pertanto dovresti passare a qualcosa del tipo:

tarticoli:
id - contatore
quantita_magazzino - numerico
[...]

tdescrizioni:
id_art - numerico
breve_descrizione - memo
descrizione_dettagliata - memo
lingua_ID - numerico

tLingua:
id_lingua - contatore
descr_lingua - testo

PS: Ho editato il titolo del 3D per una maggiore specificazione dell'argomento

legolas

paocavo, non vale, mi hai letteralmente rubato le parole dalla tastiera :D:D
Stavo pure facendo il disegnino del database con le varie relazioni.

@scura:
Quello che ti ha detto paocavo è sicuramente il miglio metodo.
Senza contare che se organizzi bene il pannello di amministrazione l'amministratore del sito può rendere il sito "universale" nel vero senso della parola dato che potrà inserire lingue infinite.

scura

Ho capito cosa dici, mi sembra una buona soluzione

l'unica cosa è che utilizzando una tbl_articoli per memorizzare le informazioni diciamo comuni e una tbl_descrizioni per es. per i testi nelle varie lingue quando inserisco un articolo vado a scrivere in 2 tabelle e mi sa che mi tocca usare T-sql se non sbaglio oppure se succede qualcosa poi mi tocca intervenire a manina giusto ?

paocavo

@Legolas said:

paocavo, non vale, mi hai letteralmente rubato le parole dalla tastiera :D:D
Stavo pure facendo il disegnino del database con le varie relazioni.

Ops! scusa per la velocità, la prossima volta mi prenderò un the con molta calma
PS: anch'io stavo facendo uno splash-screen del db...lol

paocavo

@scura said:

Ho capito cosa dici, mi sembra una buona soluzione

l'unica cosa è che utilizzando una tbl_articoli per memorizzare le informazioni diciamo comuni e una tbl_descrizioni per es. per i testi nelle varie lingue quando inserisco un articolo vado a scrivere in 2 tabelle e mi sa che mi tocca usare T-sql se non sbaglio oppure se succede qualcosa poi mi tocca intervenire a manina giusto ?

Si, potresti scrivere un Trigger ON INSERT INTO tArticoli se hai problemi di concorrenza (quanti admin ha il sito? quale RDMS usi?), altrimenti bastano due INSERT in cascata e dalla prima ti salvi l'ID_art in una variabile temporanea da usare nella seconda INSERT.

Ciao, vado a pescare!

scura

1 solo ADMIN

Io finora per inserimenti multipli ho sempre fatto 2 insert, ma vorrei migliorare altrimenti che divertimento c'è ?

Non conosco T-sql, ma vorrei imparare

Sarei orientata per utilizzare un DB access solo per via della economicità del progetto (però non è detto) certo MSSQL immagino sarebbe mooolto meglio

anche con access posso usare T-sql ?
avete da consigliarmi qualche manuale da acquistare o qualche guida online interessante ?

legolas

Io sinceramente access lo utilizzo solo per prendere gli appuntamenti con le donne .
Scherzi a parte non è il tipo di db che si presta ad un e-commerce.
Se fossi in te mi sposterei più verso Mssql (e adesso voleranno le offese) e Mysql.

Considera che quasi tutti i miei lavori in asp si appoggiano su db Mysql.
Se pensi che è pure free.

Ciao, vado a pescare!
Buona pesca

paocavo

Con MS Access non credo che potresti farlo, con MySQL penso proprio di si (è free ma non segue lo standard SQL alla lettera, anche se va benissimo per i tuoi scopi), potresti azzardare a passare direttamente a postgres...

Questo articolo potrebbe interessarti:
[url=http://www.cavone.com/database-blog/]
Problematiche tecnologiche nella scelta del RDBMS

Buona pesca

ho dimenticato di coprare l'esca...

scura

Si hai proprio ragione

ho usato per un mio progetto MSSQL e ho scoperto credo solo alcune delle notevoli differenze con access...access lo usiamo per prendere gli appuntamenti

MySQL in alternativa l'ho pensato tante volte, ma poi ho optato per MSSQL per seguire la regola PHP/MySQL ASP/MSSQL

Io non vado a pescare parto vado in vacanza proprio ora

un saluto a tutti gli abitanti di questo forum che è sempe più fico

buone vacanzeeeeeee!!!!!!

legolas

@scura said:

vacanza

Che roba è??? Si mangia???

paocavo

@scura said:

buone vacanzeeeeeee!!!!!!

Buon viaggio

Che roba è??? Si mangia???

No, si beve!!!

scura

Onestamente non me lo ricordo più...:) te lo faccio sapere quando torno

ciaooooo

madai

@scura said:

Ho capito cosa dici, mi sembra una buona soluzione

l'unica cosa è che utilizzando una tbl_articoli per memorizzare le informazioni diciamo comuni e una tbl_descrizioni per es. per i testi nelle varie lingue quando inserisco un articolo vado a scrivere in 2 tabelle e mi sa che mi tocca usare T-sql se non sbaglio oppure se succede qualcosa poi mi tocca intervenire a manina giusto ?

Scusate mi intrometto, ma tanto siete tutti in vacanza

Cosa intendi per "succede qualcosa"? Che va in errore l'insert? Programma la query affinchè non possa mai andare in errore.

Se invece intendi il problema di 2 inserimenti contemporanei che potrebbero sfalsarti le relazioni allora non temere, usa @IDENTITY per recuperare l'id dell'articolo appena inserito.

Ad ogni modo access ha dei limiti ma non me lo bistrattate, io ci ho lavorato ottimamente con tabelle da 4mln di records

Buona pesca!