Newsgroup: it.comp.os.linux.iniziare
Titolo: Linux/Debian e MySql.

Buongiorno a tutti,
 
non mi intendo affatto di database relazionali ma qualcuno sarebbe in 
grado di dirmi se esiste una relazione fra l'uso di MySql in un file 
server Debian 5.0 e la lentezza delle stampe di alcuni record che, mi 
dicono, essere notevolmente 'corposi'?
 
Grazie.
 
Markus

 wrote in message 
news:4LlFq.109289$GZ3....@tornado.fastwebnet.it...

Dipende molto da come č strutturato il dbase, dalla dimensione, da quante e 
quali SELECT o altre operazioni di accesso al data base vengono effettuate, 
da come vengono effettuate.
Mi era capitato un problema di lentezza recentemente che ho risolto una 
volta che mi sono reso conto che la tabella non aveva una chiave primaria. 
Sě insomma le informazioni fornite sono un po' scarne per poter dare una 
risposta certa.
 
Ciao.
Mik
 
 
 

 Mik
 
Ciao
Markus

 saprei quali informazioni riportare.
 
Scusa se mi intrometto, tu farai il sistemista ma qualcun'altro avrà 
fatto questo db, non conviene chiedere a costui se magari si possano 
spezzare le tabelle troppo corpose ?
 
Io conosco solo l'abc di MySql però ad esempio nelle varie guide se usi 
il motore INNODB tutti dicono di creare tabelle piccole magari 
"concatenate" tra loro con le chiavi piuttosto che una grossa contenente 
tutto...
 
Saluti !
GbMax78


Facebook: Massimo Bacilieri

 che con così pochi dati si possa dirti granché! :-O
 
la società che fornisce il gestionale VUOLE convincere la proprietà a 
sostituire il server Linux con uno sul quale installare W2003 Svr.
 
comunque grazie.
 
Markus
 
 

 GbMax78
 
Saluti.
Markus Allen

 degli indici necessari per velocizzare le select.
 
Oppure le select possono anche essere clamorosamente cannate (in genere se 
chi "progetta" il db lo fa senza utilizzare chiavi, indici o relazioni, 
allora scrive anche delle query assolutamente non efficenti).
 
Ho visto tante volte sistemi molto più carrozzati e dotati di sistemi un 
po' più seri di MySQL andare come una carrozzella in salita verticale 
perché le query facevano degli enormi prodotti tra tabelle di qualche 
centiania di migliaia di record l'una.
Riscrivendo le query (se gli indici e le foreign key sono al loro posto) 
si passava da tempi di minuti a decimi di secondo per l'esecuzione delle 
query (non sto esagerando)
 
PSK

 query (non sto esagerando)
 
So bene cosa intendi... lavoro tutto il giorno su sistemi SQL e ho visto 
/qualcosa/ anch'io ;-)


 Quindi mancano gli indici necessari ;-)
 
No, perchè alle volte l'indice NON è necessario, è semplicemente la query 
sbagliata (anche io vedo prodotti cartesiani di, per esempio 
1000*2000*300*250*10*5 quando devono prendere 2 dati da 2 tabelle. Il 
mazzolamento dello sviluppatore è quindi cosa buona e giusta in questo 
caso). 
 
Ricordiamoci che gli indici non sono gratis, occupano spazio e aumentano 
le scritture a disco.

 non cambia una fava, se indici e query del database non sono a posto.
 
Ma nel cambio, con la nuova release del gestionale ... <vbeg>
 
Ho visto cose che voi umani ...
 
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net
 

 caso).
 
Potrei obiettare, non fare di tutta l'erba un fascio, anche se cadiamo 
un po' nel filosofico.
 
Se il prodotto di 1000*2000*300*250*10*5 record lo fai lavorando su 
degli indici, magari viene fuori in 2 secondi.
Se i 2 dati li devi prendere da 2 tabelle di qualche miliardo di record, 
senza indice magari ci metti 30 secondi.
In quel caso dovresti creare un indice apposta per una query di 2 
dati... vale la pena? No... allora si fa una query apparentemente più 
stupida, ma che ne caso specifico è più efficiente.
 
E poi non parliamo del fatto che oggi le query, molto spesso, sono 
generate dinamicamente da "mostri" come hibernate attraverso interfacce 
web-oriented scritte in php o in altri framework come Seam o similari, 
per non parlare di porcherie fatte attraverso Access linkando le tabelle 
del database: e allora sì che vedi dei veri orrori!


 del database: e allora sì che vedi dei veri orrori!
 
Su questo non posso darti torto, anzi ...
Però in questi casi non si risolve né cambiando macchina, né cambiando 
sistema operativo.
 
PSK

 Oppure perché il server è clamorosamente sottodimensionato
 
Oppure perche` MySQL non e` capace a gestire le query complesse (ci sono 
passato)
 
Enrico
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
 
iQEcBAEBAgAGBQJO7NokAAoJED3SMOGZLYdYrDwH/jzjBMLDYkmE1ZKCqwTi7Civ
pSfcPcJVRg16raSK4G7nnWMVP3waFeiQQUC/V5FzxF0lJmnIe1qdNm/7qZ+UE7VZ
uLPhmgfdsEeQ0MZI8+Va3e3iTVlEgcuwLSEzemB1d1BUYd+q/uvVBcJZY+rZ3CX/
pGdPYzU1Nk3N1SQuk/iEUBmnfTxNFj2sOj0w9z9GO8kWhNyO8ms/1O94vgIgIxzp
lD04z6MsSx9g3oo7GVctj/0fSpI4UbSKgtN6TcF0h2bzz8+TPhH6G63pRTUJBoxu
g04Jk/r4Jb/673zlnB6nlLkkf5IyrpLVJKgg3dnBy+kVN4IHf0wAM3mO0B4g1S0=
=rWOb
-----END PGP SIGNATURE-----
 

 l'efficenza (tempo e memoria) dipende molto dalla query
 
Sono d'accordo con il tuo discorso, ma se una query che tira fuori un 
centinaio di record su di un database ci mette n minuti (dove n e` < 10) 
mentre su di un altro ci mette un'ora e mezza[1] (!!!), allora o il planner 
ha completamente cannato la gestione della query, oppure l'intera 
architettura del database e` sbagliata
 
Enrico
[1] e` quello che mi successe con MySQL: la query, sul server MySQL (Linux 
virtualizzato, tanta ram, tanta cpu, buon parco dischi) ci mise un'ora e 
mezza. Su di un server PostgreSQL di appoggio (Windows 2003 virtualizzato, 
512Mb di RAM, una cpu, parco dischi cosi` cosi`) ci mise 7 minuti
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
 
iQEcBAEBAgAGBQJO7NznAAoJED3SMOGZLYdYa1oH/2lQl1aJj9WLYbwNi+QevJfp
3fCKP0yaRlY8xai8glbuEBJFXFFNbE49jCvpRyxdA8pK65oqrmbBVYGeADH2cyoi
uJMNgE/aCH6xPbU2/t0czWSVfVhiETQrExhiaTZgGtEIPeEioxDc8MgxKVKjPWzd
1naqxApxYg+RJoU7s4ZRG0i8eE+N3xrn1ZdJKKSbTx+mu8ACx3YT66LCoNRKDhnn
whG3ApnnSMVSPVqNzOCBcuwqcDs3NekejM0WnKccroe8htaEgRAzdy+HasYhSVCX
f9njgZfzT0iPS9scjEXR9wrd14Dk0KSSELzicy7PZaZ+NgSnGFB9GnmAGpeWAhg=
=TkPO
-----END PGP SIGNATURE-----
 

 spezzare le tabelle troppo corpose
 
Chiedere ad uno sviluppatore se ci sono problemi all'applicativo e` una 
bestemmia. Il problema e` *sempre* causato dal dimensionamento hardware o 
dal sistema operativo che ospita il sistema (risata amara)
 
Enrico

 Markus
 
alla fine dei conti ho saputo quello che mi serviva e, cioè, che la 
colpa _non_ è imputabile alla macchina.
 
ringrazio tutti.
 
Markus Allen