Newsgroup: it.comp.lang.delphi
Titolo: Quale DB ?

Buon giorno a tutti.
Ho un problema, fino adesso ho utilizzato Paradox  per sviluppo applicazioni
professionali in  rete ma gli utenti non aggionavano simultaneamente gli
archivi principali.
Ora devo sviluppare una procedura "corporosa" (4-5 mesi di lavoro)  con 4-5
client + 1 server (per ora NON dedicato) e archivi stimo arrivino fino ad un
massimo di 20.000 record
Il cliente è un tipo "rognoso" quindi NON posso sbagliare di un niente e
ovviamente vuole:
- velocità :è abituato ad una procedura ancora in DOS (quasi rimpianto sigh
!) in rete ma propirio perchè in DOS veloce anche se con alcune limitazioni.
- integrità dei dati
- possibilià di espandersi  a 7/8 client
 Onestamente su Paradox non ho mai avuto da ridire granchè, l'ho ritenuto
abbastanza sicuro, facile da installare, utilizzare e soprattutto veloce
(grazie a utilizzo tabelle invece di query) anche su archivi di 20.000
record e più)
Ora sono a un bivio continuo con paradox o vado sul moderno ?
Ho fatto prove con Mysql e Firebird (Interbase) e delphi 6 prof. (vorrei
provare PostgreSql)
Firebird mi è sembrato più facile d'installazione (forse un pò più lento in
scrittura) ma li ho provati solo in locale crenando tabelle di 100.000
record ( e firebird utilizzando le grid mi è sembrato più veloce forse
utilizza meglio unn sitema di cache)
Comunque, condiderando che è esenziale la velocità e la semplicità di
amministazione (il livello medio del personale del cliente è basso) e
soprattutto deve essere veloce da imparare cosa mi consigliate ?
Inoltre sono abituato a lock pessimistico mentree ho visto che firebird usa
ottimistico (gli altri non so') e questo temo mi provochi dei problemi in
quanto alcune tabelle (tipo articoli) potranno essere aggiornate
simultaneamente su più campi valore (es. carico, scarico, ordinato ecc.) è
il lock ottimistico mi sembra di difficile gestione.
Ultimo cosa devo decidere in frettissima altrimenti non riesco a rispettare
i tempi di consegna (una parte a entro Natale) e vorrei passare le feste con
la mia bimba e non dal cliente.
Avrei tante altre domande ma ho paura di essere già stato lungo.
N.B. è la prima volta che mi affido alle news group direttamente e devo
ancora imparare il bon-ton.
Grazie in anticipo.

per non "cambiare troppo mentalitą" puoi provare DBISAM della
ElevateSoftware (a pagamento) o il local server (gratuito) della
http://resolution.extendedsystems.com/ADS/default.htm
Ciao
Marco
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 per non "cambiare troppo mentalità" puoi provare DBISAM della

Grazie Marco sei stato tempestivo ma io volevo affidarmi ad un open-source.
Mi sbaglierò credo che saranno il futuro e comunque credo sia più facile
trovare eventualmente aiuto e documentazione in giro per la rete.
Ciao Guido.

con supporto nativo sotto win e per sfruttare le potenzialità in rete
trovi zeos db + interbase (alternativamente mysql)
per maggiori info google è da quella parte --->
per problemi siamo qui ;-)
ciao f
-- 
Coltiva linux, che tanto windows si pianta da solo!
Linux registered user: 364664 (
http://counter.li.org
)

il lock ottimistico mi sembra di difficile gestione.
Uno dei pressupposti di un RDBMS è quello di garantire la concorrenza. Se
in alcuni casi è necessario bloccare un record, esistono di solito comandi
per farlo, ma sono specifici di ogni DB. Comunque anche Delphi ha delle
funzionalità per verificare se il record è stato modificato prima di
scriverlo. Una volta presa la mano, non è difficile da gestire.
Luigi D. Sandon - D&amp;D Support Team
--- posted by geoForum on 
http://www.delphiedintorni.it

funzionalità per verificare se il record è stato modificato prima di
scriverlo
1) se decido di usare Firebird quali sono questi altri comandi ?
alcuni DB utilizzano SELECT FOR UPDATE per lock pessimistico ma Firebird ho
letto che non produce risultati coin questo comando e allora quale usare ?
2) quali sono le funzionalità di Delphi che indendi ?
Il problema non è cambiare mentalità perchè vorrei usare SQL anche con
paradox se non altro per "prepararmi il futuro" il problema è la velocità,
l'utilizzo delle DBgrid. e il lock almeno che non mi si spieghi come fare a
controllare con lock ottimistico quali campi sono variati e come intervenire
(senza memorizzare ogni valore in variabili per poi fare confronti tra vecci
e nuovi valori), considerando che gli utenti varieranno in continuazione
quesri campi.
Altra domanda, sempre considerando Firebird: perchè un ricerca (ad es.
DBLookUpCombo) su un campo chiave è lenta (creato file di test con 5 campi e
70.000 recod). se uso un order by su indice primario o secondari non
capisco perchè la ricerca dovrebbe essere lenta.
Il problema è il comando lookup dei combo ?
Se sì come posso ovviare?
Il collo di bottiglia sono i controlli DBaware ? (DBCombo e simili e Dbgrid)
Se sì cosa uso considerando che ormai nessuno untilizza un form data-entry
senza griglia per visaulizzare dati inseriti (es. componenti distinta base o
righe fattura) e senza un combo per ricerca degli articoli o dei clienti ?
Attendo con ansia, mi avete abituato bene. Ciao Guido

 Attendo con ansia, mi avete abituato bene. Ciao Guido
il problema è si il dblookup che si deve caricare in memoria tutti e
70mila i dati per farteli vedere. E' proprio qui la differenza che ti
dicevo. alcuni componenti ti forniscono dei controlli dbaware che ti fanno
il fetch dei campi su richiesta. anche se tu glieli chiedi tutti loro ti
prelevano solo i primi 50 ad esempio e mano a mano che tu scorri la
griglia loro prelevano i restanti. in questa maniera cercano di
alleggerire il lavoro del server.
però tu puoi usare uno stratagemma. nel dblookup carichi i campi dopo che
l'utente ha digitato le prime lettere del campo in modo che tu applichi un
filtro prima di caricare il tutto. in questa maniera non fai il fetch di
70000 campi ma riduci un po lo spettro.
altrimenti potresti caricarti un clientdataset che si tiene i dati in
memoria interrogando il server una sola volta.
ciao


Con tutto quanto ha firebird non vedo che incasinarsi con MySql che 
molte comodità non le ha.
Riguardo il numero di client, no problem.
La mole di dati che dovresti gestire per firebird è una passeggiata.
Alberto Salvati
A *Neapolitan* delphi developer who is studing c# & .Net
"Dicette 'o pappece 'nfaccia 'a noce dammi 'o tiempo che pure te spertoso!"

 L'unico problema e che facendo così mi stimolate la curiosità:
Alleulja!!!!! ;)
-- 


Il problema è il comando lookup dei combo ?
Secondo me dovresti cambiare il tipo di approccio ( parere personale :-)
), non caricare tutti i dblookup all'inizio soprattutto se i record sono
molti, così rallenti il caricamento della form oltre ad appesantire ( a
livello di memoria ) il programma, ma invece, fai per ogni lookup una
select "secca" per ricavare la descrizione relativa a quel codice presente
nella form, vedrai che così migliori le prestazioni di caricamento della
form. Per quanto riguarda la visualizzazione dei record di lookup io di
solito non uso i controlli dblookup ma un form con una griglia dove carico
solo i record selezioanti dall'utente.
P.S.
Se non ricordo male quasi tutti i componenti sopracitati dovrebbero avere
una proprietà "fetchall" di tipo boolean dove puoi dire se caricare tutti
i record oppure una parte demandando al componente stesso la gestione.
Ciao da Enrico Giudici.
ico...@tiscali.it


 trovi zeos db + interbase (alternativamente mysql)
Volevo segnalare una cosa:
con Firebird e zeoslib ho trovato parecchi problemi, sembrano dei piccoli
bachi soprattutto nella gestione dei tipi floating (decimal) in stored
procedure
Ho deciso di usare i componenti IB di delphi
In azienda usiamo i componenti ibobjects (a pagamento, ma dal costo
contenuto) sia per IB che FB e vanno bene, tra l'altro il costo non è
assolutamente esagerato!
FB su rete locale è veloce e ben performante, soprattutto se le tabelle (ne
ho una con 35 milioni di record!) anno indici e chiavi primarie ben
realizzate
Andrea

 solo i record selezioanti dall'utente.
Grazie del consiglio Enrico, ma temo non sia applicabile nel mio caso:
immagina una specie di scheda techina di un articolo in cui l'utente può
inserire diversi dati tabellati e una distinta base prendendo  i dati da un'
altra tabella di alcune migliaia di codici.
Se gli propongo di aprire tutte le volte un form, impostare parametri di
ricerca ecc. e questo  15/30 volte per articolo il cliente (e soprattutto i
dipendenti che inseriscono i dati) mi sparano.
Purtroppo tutte le procedure attuali utilizzano in molti casi campi di
lookup tipo dbcombo che permettono generalmente inserimenti veloci.
la select "secca" non è applicabile in un dbcombo nel senso che non ha
senso, credo, per la stessa definizione di "combo" ma và sicuramente bene se
utilizzo ad es. un textbox e una label per decodifica dei dati.
Ora comunque ho ilproblema di fare vedere il database del server FB con il
client.
Il programma delphi mi dà un errore anche se non capisco perchè, in quanto
l'errore è dato già in fase di caricamneto programma quando ancora nopn
tenta nessun collegamento col DB.
Non è che usando i controlli Interbase di delphi 6 devo portarmi dietro
qualche altra dll per l'installazione del programma su client ?
Boh !
Ciao e grazie
Guio

e senza un combo per ricerca degli articoli o dei clienti ?
Devi implementare delle ricerche che generino una query adatta, non che
scarichino 15.000 clienti e 70.000 articoli tutti in una volta. Ad esempio
digitando parte del codice cliente o articolo, o parte della ragione sociale.
Luigi D. Sandon - D&amp;D Support Team
--- posted by geoForum on 
http://www.delphiedintorni.it

Guio
Di solito per il client basta avere nella system directory di windows la
dll gds32.dll ( sto andando a memoria ), per essere sicuro potresti
installare il client sulla tua macchina ( l'installazione di Firebird lo
prevede ).
Ciao da Enrico Giudici



Grazie per le risposte.
Quindi vediamo se ho capito bene i vostri consigli.
Supponiamo un form (tipo anag.clienti):
a) Codici IVA (saranno una 30 al max) va bene DBCombo
a) Codici Pagamento (saranno una 50 al max) va bene DBCombo
a) Codici Banca (saranno un 100 al max) va bene DBCombo
ecc. per tabelle piccole
Ricerca cliente o articoli per cliente o listino cliente-articolo
ovvero dopo posso aver equalche migliaio di articoli una form ulteriore di
ricerca (al limite ANCHE una cobo a rischio e pericolo del cliente).
Giusto ?
Ciao Guido.