un consiglio al volo su myisam e innodb

[artax]

Ciao atutti,

devo creare un db per hotel e locazioni geografiche che conterrà moolti dati. Tabelle del tipo

_HOTEL con circa 150.000 records e vari campi tra cui un id_citta che punta a

_CITTA con circa 20.000 records e vari campi tra cui un id_regione che punta a

_REGIONI con circa 1000 record e vari campi tra cui un id_nazione che punta a

_NAZIONI con circa 150 record

Meglio myisam o innodb?

Inoltre ho un dubbio sulle citta, in quanto ogni citta deve essere memorizzata con il nome originale e fino a 5 traduzioni (per esempio torino ha solo TORINO e TURIN). Lo so che dovrei suare una tabella _CITTA_NOMI con una relazione alla tabella città con unr ecord per ogni traduzione, ma a livello prestazione, non mi conviene aggiungere semplicemente dei campi all'attuale tabella _CITTA del tipo "italian", "french", "english".... Le lingue in tutte sono 6.

[neida]

In questo articolo puoi trovare delle utili informazioni, anche se personalmente mi sento di consigliarti le MyISAM se non hai necessità di utilizzare "transazioni", "vincoli di chiave esterna" o "ripristino da interruzioni". Funzionalità specifiche offerte solo dalle tabelle InnoDB.

Riguardo poi alla situazione della traduzione dei nomi delle città, penso sia meglio utilizzare una tabella dedicata anziché vincolare i dati ad un numero di campi (possibilità) limitato. Nel tuo caso ahi detto di voler rendere disponibili solo 6 lingue, ma cosa accadrebbe se in futuro dovessi, per qualsiasi motivo, aggiungerne altre? E' comunque una cosa da valutare preventivamente, le modifiche fatte in un secondo momento comporterebbero non pochi problemi...

[clasku]

Perché invece non fai una tabella città per ogni lingua? Poi, a seconda della lingua scelta dall'utente richiami la tabella giusta...

Ah, quoto neida, se non hai problemi di chiavi esterne usa le tabelle MyIsam, le trovo più "snelle"

[artax]

Grazie ad entrambi per la risposta.


Sono ancora indeciso sulle citta.

Fare una tabella per ogni citta potrebbe essere comodo, ma il fatto è che non tutte le città hanno una traduzione. Per dire Parigi ne ha svariate in ogni lingua del mondo, ma città più piccole no. Pensate ad Hannover per esempio... quindi in realtà il nome "originario" sarà spesso quello prevalente.

C'è da dire che il sito andra su di un server dedicato, quindi non ci sono problemi di spazio in database, mi interessa solo la velocità nelle query di selezione...

Per le lingue è probabile si arrivi a 8, ma mooolto piu in futuro.

Con la soluzione da me proposta (una colonna "italian", una "french"...) per esmpio un solo record per Hannover, con tutti i campi di linga uguali "hannover". E' vero, tanto ridondanza, ma mi basta fare SELECT italian FROM tab_citta per avere tutti i nomi a portata di mano.

Con una tabella relazionale avrei molto meno casino in db ma tanti tanti tanti JOIN da fare.

Infine, con la soluzione di clasku avrei una selezione rapida e non una eccessiva ridondanza, se non per i dati fissi di ogni citta.

Non so scegliere.

[clasku]

Beh, se dici che si pensa di estendere il numero delle lingue (anche in un futuro remoto) io non farei una tabella unica per tutte le città. Quando la dovrai aggiornare credo che sarebbe un bel casino... Poi, se non hai problemi di spazio...

Prevenire è meglio che curare!

[artax]

Non hai tutti i torti, il mio unico dubbio è che comunq ua select diretta è meglio di un Join, o sbaglio?

[clasku]

in termini di velocità... forse no...

ma come stress del server mi sa che è meglio una select diretta... dovrebbe occupare meno il server... dovrebbe