Newsgroup: it.comp.lang.visual-basic
Titolo: Performance database

Ciao ragazzi,
ho una applicazione scritta in VB6 che, per motivi che non sto a
spiegarvi, deve eseguire numerose query su un database con parecchie
tabelle.
Queste query (semplificando il discorso) sono tutte del tipo "Prendi il
campo X dalla tabella Y con record ID=Z", ovvero sono tutte query
eseguite su tabelle separate e che restituiscono un solo valore (ovvero
un singolo campo) di uno specifico record.
La domanda e' la seguente: qual'e' secondo la vostra esperienza la
combinazione DAO/ADO + database piu' performante in questi casi?
DAO + MySQL
DAO + MSDE
DAO + MS SQL
ADO + MS SQL
ADO + MySQL
....... ???
Premetto che attualmente viene utilizzato DAO 3.6 + Database Access
(Jet 4.0) ma ho necessita', per ovvi motivi, di passare ad un database
piu' robusto (MS SQL, MySQL, Firebird, Oracle, Pervasive o quant'altro
possiate suggerirmi).
L'applicazione viene utilizzata normalmente da una decina di utenti.
Secondo la vostra esperienza qual'e' la soluzione migliore?

 Secondo la vostra esperienza qual'e' la soluzione migliore?
un qualsiasi database client server (quindi NO access), con le tabelle
ben indicizzate in base alle query che devi fare.
valuta anche l' opportunita` di spostare il codice SQL piu` pesante su
stored procedures:  ad esempio, se adesso devi fare dieci lookup prima
di ottenere un certo risultato definitivo, mettili tutti in una stored
procedure che ti restituisca solo l'ultimo valore.
-- 
ciao, hal

Ciao Hal,
grazie dei suggerimenti.
Per quanto riguarda il discorso degli indici, questi gia' ci sono, in
quanto per questo specifico problema praticamente i JOIN sono
inesistenti.
Stiamo parlando di query tutte del tipo:
SELECT NomeCampo FROM NomeTabella WHERE IdChiavePrimaria=N
La mia domanda era su qual'e' secondo te, a livello di performance, la
combinazione migliore (indipendentemente dal costo delle licenze del DB
server, ecc.)

Scusa. Ovviamente l'indice su IdChiavePrimaria e' presente

 server, ecc.)
bisogna anche considerare l'hardware su cui deve girare il database,
chi e come deve gestire la  manutenzione del sistema (macchine e db)
e del software.
le dimensioni del database possono essere un aspetto da considerare:
con oracle mi sono sempre trovato bene con database grandi, ma c'era
anche un signor hardware sotto.
anche sql server puo` fare la sua  bella figura, pero` ha il difetto
di girare solo su windows e tende  ad integrarsi troppo nel S.O.. 
in compenso, visual basic lavora bene con sql server ed un eventuale
upgrade da access e` facilitato da apposita procedura guidata.
va rivisto naturalmente  il codice del  client che, se  pensato all'
origine per access,  avra` probabilmente delle Seek e delle Find che
sono da buttare nel cesso.
non ho mai lavorato seriamente con mysql, mentre ho fatto esperienze
positive con sql anywhere di sybase (non so se esista ancora).
diciamo che, se ti trovi bene con gli  ambienti  microsoft, potresti
avallare l'impiego di sql server.
-- 
ciao, hal

salve,

non ho esperienza relativamente a Firebird, Oracle e MySql, solo piccole 
esperienze PostgreSQL oltre a SQL Server, quindi la mia risposta potrebbe 
sicuramente essere "di parte"...
sconsiglierei comunque DAO in quanto specificatamente calibrato e disegnato 
su JET, e chiaramente consiglierei almeno ADO, se proprio vuoi rimanere in 
ambito COM...
relativamente a SQL Server/MSDE non dovresti avere problematiche particolari 
anche se, in determinati ambienti, il passaggio da JET a veri server di 
motori relazionali puo' comportare delle "penalizzazioni" in termini di 
performance, dipendenti sicuramente dal diverso tipo di ambito..
JET e' veramente un fulmine in ambito locale con tabelle poco popolate, ma 
le sue prestazioni tendono a decadere in ambito multiutente, specialmente 
per database corposi, e talvolta si incorre anche in problematiche di 
sicurezza fisica del file di database... diversamente i motori comunque 
riportati offrono una sicurezza e stabilita' non paragonabile a JET stesso, 
malgrado la possibile penalizzazione in alcuni ambiti di performance..
il loro lavoro chiaramento meglio lo svolgono utilizzando appropriatamente 
le "regole" relative alle interrogazioni, quindi filtri di where appropriati 
onde recuperare il numero minimo di righe da manipolare e non mostruose 
SELECT * FROM incondizionate...
saluti
-- 
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtm
 
http://italy.mvps.org
DbaMgr2k ver 0.16.0  -  DbaMgr ver 0.61.0
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual 
interface)
--------- remove DMO to reply 

Grazie a tutti per i suggerimenti
Faro' un po' di prove

 un singolo campo) di uno specifico record.
Quanto a performance, qualunque strumento, eccetto ovviamente Access 
che è file based, se ben indicizzato e montato su macchine decenti, ti 
fornirà prestazioni elevatissime.
Quanto a librerie, sicuramente ADO+OleDb è la scelta migliore, visto 
che DAO va bene per Access e poco altro, e ODBC comunque è una 
complicazione ed un rallentamento inutile.
Fra gli strumenti dbms-server, oltre alle performance che, come dicevo, 
fino ad un certo carico si possono considerare equiparabili (e se oggi 
vai su Access, sei ad almeno un ordine di grandezza 100 dal livello in 
cui potrai percepire lievi differenze), devi considerare anche la 
disponibilità di strumenti di supporto come manualistica e gruppi di 
discussione.
In questo, Oracle e Ms-Sql/MSDE sono imbattibili. Gli altri sono un po' 
assenti in rete, e se ti inchiodi su qualcosa ti tocca ricorrere 
all'assistenza ufficiale ($$$).
Non ultimo, considera che di quelli che citi, MSDE è l'unico gratuito 
(e non è poco...).
Ciao
Alberto
-- 
A questo punto hanno trovato un muro,
un muro duro, molto molto duro,
che siamo noi.