- Home
- Categorie
- Coding e Sistemistica
- Altri linguaggi per il web
- Struttura DB [Multilingua]
-
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 - testoecc...
oppure
ID - contatore
Nome - testo
Lingua - numericoecc...
???
-
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.
-
@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
-
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 - numericoHo 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 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
-
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 - numericotLingua:
id_lingua - contatore
descr_lingua - testoPS: Ho editato il titolo del 3D per una maggiore specificazione dell'argomento
-
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.
-
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 ?
-
@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
-
@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!
-
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 ?
-
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
-
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 RDBMSBuona pesca
ho dimenticato di coprare l'esca...
-
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!!!!!!
-
-
-
Onestamente non me lo ricordo più...:) te lo faccio sapere quando torno
ciaooooo
-
@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!