Newsgroup: it.comp.os.linux.sys
Titolo: InnoDB, utilità???

Ciao a tutti,
Sapete come funziona InnoDB integrato con MySQL? Dovrebbe migliorare le
performance del sistema oppure viene utilizzato per migliorare la
sicurezza, ma consuma risorse?
Ho letto un po' di documentazione, ma sinceramente non ho capito bene a
cosa serve!!! Visto che me lo ritrovo installato e funzionante vorrei
capire se vale la pena di mantenerlo o meno.
Grazie.

 capire se vale la pena di mantenerlo o meno.
http://sunsite.mff.cuni.cz/MIRRORS/ftp.mysql.com/doc/en/ISAM.html
Qui trovi tutti i tipi di tabelle e le caratteristiche.
Innodb fondamentalmente permette a mysql di supportare transazioni trigger
e roba simile.
Qui

 
Ma quindi, permette di ampliarne l'utilizzo, aggiunge nuove
caratteristiche, ma non di migliorare le prestazioni, giusto?

 caratteristiche, ma non di migliorare le prestazioni, giusto?
Dipende dal contesto di utilizzo. In alcuni casi migliorano, in
altri peggiorano (rispetto a MyIsam).
Forse il thread sarebbe piu' IT su it.comp.software.database. 
Fabio

pollom ha scritto:

in generale usare tabelle transaction-safe peggiora le prestazioni
x l'ovvio overhead nel commit (poi i casi estremi, con un sacco di
accessi contemporanei in scrittura per es., non saprei, la domanda
mi sembra semplicistica e quindi la risposta deve rimanere banale)



In sintesi, se non usi o se non sai cosa sono i trigger, l'integrità
referenziale e le transazioni, usa mysql "lissio" che fai prima.
Tendenzialmente, per come sono scritti i software opensource disponibili,
non ce n'è bisogno.
Max

 capire se vale la pena di mantenerlo o meno.
Se ti servono le features che offre si. Se no, vai di MyISAM.
ciao, f.

 non ce n'è bisogno.
un paio di palle. questa generalizzazione e' banale e superficiale.
Dipende dal programma.



"tendenzialmente" non mi pare che sia qualcosa di esclusivo, totalitario
che esclude ogni altra possibilità!
Mi pare ovvio che dipenda dal programma ma per gli usi più comuni, le
innodb non vengono usate.
Max


un qualsiasi programma che fa uso di integrita' referenziale con mysql
necessita innodb. e con i db l'integrita' referenziale non e' poi cosi'
rara....

 rara....
Con i DB no.
Con Mysql si.
Nel senso: la maggior parte del SW OS per "uso comune" in circolazione
che sia pensato per girare su Mysql *non* fa uso di quelle funzionalità.
Questo, credo, sia un dato di fatto.
Credo Max intendesse semplicemente questo...

 Credo Max intendesse semplicemente questo...
Yes, exactly. Grazie
Max

 Questo, credo, sia un dato di fatto.
Fantastico :)
MySQL caga poco la consistenza dei database, quindi le applicazioni cagano
poco la consistenza dei database, risultato la gente si ritrova con
database corrotti ed è contenta!
-- 
 Daniele Orlandi                                                        つづく


non direi cosi'. E' che la gente usa i mysql per delle robe banali.

 non direi cosi'. E' che la gente usa i mysql per delle robe banali.
O situazioni non banali ma in cui la "coerenza da garantire" è poca ma
la quantità di accessi e dati tanta.
Classico esempio un DB di autenticazioni, che ha un utilizzo molto
diverso da quello di un gestionale o altra situazione di DB "complesso".

 database corrotti ed è contenta!
E' un problema storico di mysql.
Agli albori era velocissimo (solo con le isam e myisam) ma la
transazionalità non sapeva cosa era. 
Pian piano mysql è cresciuto ed è diventato una babele di tablespaces,
perdendo ovviamente di prestazioni se si pretende di usare la roba nuova,
ma i programmatori hanno comunque mantenuto l'abitudine di utilizzare le
tabelle liscie, sena controlli di integrità lato server.
Dopotutto, tali controlli sono implementabilissimi via software.
Non che non si possano fare, semplicemente quello che su oracle o postgres
non lo pensi nemmeno, su mysql lo devi controllare.
Max

 Dopotutto, tali controlli sono implementabilissimi via software.
Sì, sì, i controlli fatti dagli applicativi te li raccomando...
Tutte le volte che ho dovuto fare delle elaborazioni sui dati 
"controllati dagli applicativi" ho perso dei giorni a rimettere a posto 
tutta la fuffa che c'era finita dentro. E pensare che c'è ancora 
qualcuno che rimpiange il db3...
-- 
Seven-hundred tons of metal a day
Now sir you tell me the world's changed
Once I made you rich enough
Rich enough to forget my name

 Pessima abitudine, IMHO (e non solo mia).
Oh non fraintendiamo.
Io sono daccordo con te che l'integrità referenziale andrebbe usata.
Non è mica colpa mia se spesso non la usano.
Forse perchè la maggior parte degli isp NON fornisce mysql con innodb di
default ?
Insomma... non posso che concordare che sia utilissima, ma non continuate a
replarmi come se io la giustificassi e la appoggiassi a spada tratta.
Cazzo ci azzecco io col SW scritto dagli altri ??
Max

 Cazzo ci azzecco io col SW scritto dagli altri ??
E' colpa tua e basta.
Fine del discorso.
:-)
P.S.: Che bello, al prossimo bug che scoprono nel mio codice so a chi dare 
la colpa :-)))

 database corrotti ed è contenta!
Ma consistenza dei dati (che è l'attuale argomento) e database corrotti (che
l'argomento di altri database) non sono un tantinello cose diverse?

 "controllati dagli applicativi" ho perso dei giorni a rimettere a posto
]zac[
Premesso che le reference key sono utili ed era ora che fossero
implementate, ma dubito fortemente (dammi credito di una certa piccola ma
prolungata esperienza) che la 'fuffa' sia dovuta alla mancanza del link fra
tabelle, ma spesso a una errata progettazione dei riferimenti (astratti)
fra le varie tabelle, delle chiavi primarie e non, di tipi di database ben
poco solidi, e molto poco alla mancanza delle reference key (che devono
essere usate poco e bene e che possono pesare sensibilmente nelle fase di
inserimento/modifica dei dati).
In ogni caso, per esempio, presupporre che tutti i codici di articolo di un
ordine cliente siano tutti presenti nell'anagrafica di magazzino è un
grosso errore di progettazione, per altro risolvibile con poco sforzo, cosa
per altro utile negli altri nove miliardi di casi (codice iva, listino,
sconto, mancante o balordo).
In sintesi, in progetti che non siano piccolissimi, in teoria le refence key
sono utilissime/vitali, in pratica, tenendo conto che molti controlli tocca
farli comunque, sono uno strato di sicurezza simpatico/utile in certe
occasioni (ad esempio nell'importazione di dati).

 (che l'argomento di altri database) non sono un tantinello cose diverse?
Basta accordarsi sulla definizione di corrotto.
Un database inconsistente rientra nella mia definizione di corrotto.
Ciao,
-- 
 Daniele Orlandi                                                        つづく