Newsgroup: it.comp.lang.visual-basic
Titolo: db freeware

Salve a tutti, sviluppo gestionali in visual basic e vorrei cominciare
ad usare DBMS seri e freeware, che non siano quindi Access o i vari
colossi conosciuti (Oracle, MSSQLServer...).
La scelta era quindi caduta su 4 DBMS:
mysql, postgreSQL, firebird e sapdb.
MySQL è da scartare per i gestionali, in quanto manca di alcune
features fondamentali (integrità referenziale, stored procedures,
trigger, ecc...).
PostgreSQL è ottimo, ma dicono che è problematico installarlo su win
in quanto gira grazie ad una shell unix.
Rimangono Firebird e SapDB, e sinceramente non so esattamente quale
sia migliore (per la mia situazione intendo).
A quanto mi pare di aver letto entrambi sono molto potenti,
supportando tutte quelle features che hanno i db maggiori non
freeware.
Le cose importanti rimangono quindi: la licenza e la loro usabilità in
visual basic.
Firebird ha la licenza IPL (non so esattamente cosa voglia dire),
mentre SapDB è opensource (GPL). La cosa che vorrei sapere è se
utilizzando uno dei 2 in un programma da commercializzare, anche il
programma deve essere GPL?
Per quanto riguarda l'usabilità in vb non so praticamente niente.
Quale dei 2 ha i driver ODBC ( o OleDB, sempre freeware ) migliori e
stabili?
ciao e grazie per l'attenzione.
P.S. ovviamente se mi sbaglio in qualcosa (tipo la difficoltà di usare
PostgreSQL su win), sarei contento di essere contraddetto...=)

 PostgreSQL su win), sarei contento di essere contraddetto...=)
Ho scritto dopo aver letto questa tua disponibilità.
Scusa la franchezza e l'assenza di aiuto. ;-)

Scusa la franchezza e l'assenza di aiuto. ;-)
Ci mancherebbe, hai fatto bene...=)
In definitiva, quale usi? Se non ho capito male access....
ciao

 In definitiva, quale usi? Se non ho capito male access....
Avendo al 99% installazioni da 1 a 6/7 posti di lavoro max, uso Access con
DAO. Per il resto (veramente irrisorio) uso SQL Server con ADO.
Aggiungo che sono stato costretto a usare ADO perchè dovevo usare SQL
Server, altrimenti avrei buttato (come butterei) alle ortiche anche ADO per
le sue prestazioni ridicole.
E ora non dite "...Lupo che palle...", ho risposto a una domanda.
... che poi me la sia "procurata" è un altro discorso... :-P

... che poi me la sia "procurata" è un altro discorso... :-P
ehehehehhe....=)))

 sfruttarlo?
Perchè il giorno in cui il DBMS viene cambiato con un altro che gestisce le
cose in modo diverso/non le gestisce più sei a terra.
E perchè dovresti cambiare DBMS (dopo tutta la fatica fatta a sceglierlo)?
:)
Magari solo perchè quello scelto ti cambia i termini della licenza.
O perchè non viene più supportato.
Sono comunque cose da valutare e scegliere la più conveniente in base a
preferenze/convenienza.
Ciao
--
Math Parser : 
http://www.neodatatype.net
Sito Comune : 
http://www.it-lang-vb.net

 cose in modo diverso/non le gestisce più sei a terra.
Ma allora perché utilizzare un database e non crearsene uno da soli...
Sinceramente *non* utilizzare trigger, stored procedure, integrità
referenziale per paura di trovarsi in difficoltà nel caso si dovesse
cambiare db significa soltanto avere dato un errato design
all'applicazione.
Sono funzionalità importantissime e difficilmente se ne può fare a meno...
Ciao.
-- 
BSD is for UNIX lovers -- linux is for Windows haters.

 visual basic.
Su questo non ti so rispondere.


 all'applicazione.
O essersi già scottati una volta e avere i fogli di ottima progettazione
arrotolati in bagno :)


Ciao.
ciao

ciao

 arrotolati in bagno :)
Vedi sopra.. con tutto ci si può scottare, quindi o non si utilizza
nulla o si fa in modo che sia meno traumatico possibile il cambio...
E questo è ottenibile spiegando ai programmatori che quei fogli sono
troppo ruvidi per poter essere utilizzati per... :-P


 che è molto buono chi il contrario).
In questo campo è molto facile sentire opinioni discordanti...


 Sono funzionalità importantissime e difficilmente se ne può fare a meno...
Dipende... il punto non e' tanto "mi paro il c**o per il futuro", quanto che
potresti avere bisogno *subito* di supportare formati DB differenti, e a
questo punto un approccio dove la logica e' gestita internamente ha i suoi
vantaggi.
Noi sviluppiamo internamente su SQL Server, e installiamo potenzialmente su
tutto quello che gira con ODBC... cambiare database per quanto ci riguarda
e' questione di cambiare un file INI, e piu' componenti su una singola
installazione possono essere dirottati su DB differenti, anche "strada
facendo"
Con un design sufficientemente accorto, dove tutti gli accessi al DB sono
ben incapsulati in classi, implementare concetti come integrita'
referenziale e trigger e' assai banale, e del tutto trasparente per il resto
dell'applicazione...
Ciao
--
Luca Dormio - 
luca....@tin.it
________________________________
"Marty, non stai ragionando in maniera quadridimensionale"
Dr. Emmett L. Brown

 ha scritto


PostgreSQL su win), sarei contento di essere contraddetto...=)
oddio, cygwin ora funziona una meraviglia: ti sto scrivendo da un pc
dove ho window maker sul desktop. ma l'installazione non e' alla
portata di tutti. anzi...
comunque secondo me un server dedicato al db e' sempre un buon
investimento. ma sono opinioni, come tutte le altre che scrivo sempre.
saluti.
-- 
Gianni Rondinini
Icem s.r.l.
Tel: 
+39 0545 78036
Fax: 
+39 0545 78727

dita, quindi il meglio è non fare nulla...
insisto col c :)
un compilatore c c'e' per tutte le cose con un piedino indicato "ck" e
se un giorno non ne scriveranno piu' ci saranno sempre quelli attuali
che continueranno a funzionare bene :)
saluti che ho vinto :D


port nativo per Windows. Comunque non dovrebbe essere più di tanto
a dire la verita', il port su windows l'hanno eliminato a partire
dalla 7.0.2. prima c'erano i binari che andavano bene anche in nt/2k.
sai che abbiano ripreso a lavorarci sopra?
saluti.


dell'applicazione...
Questo aspetto potrebbe essere affrontato in 2 modi diversi:
1. Metto tutto la logica nel codice sul client, creando classi che
implementano i concetti gia' disponibili nel server (stored, trigger).
In pratica sfrutto il db semplicemente come deposito di dati in
tabelle.
2. Dove ritengo opportuno sfrutto "l'intelligenza" del server con
stored e trigger, creando versioni diverse di procedure per i database
ai quali penso di connettermi
Io ritengo che l'approccio n. 1 sia la causa principale
dell'appesantimento degli eseguibili, sia come velocita' che come
grandezza: a meno di avere clienti con l'ultima versione di hardware,
cosa che a me non capita avendo a che fare con ditte che lavorano
ancora con Windows 98 e 32 MB di ram, questo per me e' un aspetto
assolutamente da non sottovalutare.
Il punto 2 richiede di "smazzarsi" i vari linguaggi di programmazione
dei server (Transact SQL, PL/SQL, etc.), ma del resto come
programmatore sono pagato per questo. Il cliente dopodomani vuole
cambiare il DBMS ? Paga il porting.
 
Ciao :-)
--
Database Gate - The Powerful SQL Editor
HD Checker - The S.M.A.R.T. Hard Disk Reader
Asus Checker - CPU and Asus MB Checker
http://www.sgr.info

 cambiare il DBMS ? Paga il porting.
E' tutto corretto, posso aggiungere che per lo piu' l'appesantimento della
procedura si sente in contesti meno delicati, in fase di aggiornamento
cioe',  rispetto a quelli che il cliente in genere vede sempre come
requisito piu' critico, la consultazione.
La tua ultima affermazione peraltro sottolinea come certe scelte spesso non
sono di tipo strettamente tecnico ma sconfinano anche nel commerciale... nel
nostro caso, ad esempio, non forniamo quasi mai soluzioni complete
"software+db", perche' direi che nel 80% dei casi ci viene chiesto di
appoggiarci un RDBMS esistente; trovarci nella situazione in cui, se il Db
non supporta certe caratteristiche, non possiamo utilizzarlo (uno a caso
MySQL e trigger) significa perdere un cliente...


saluti.
ciao

 dell'applicazione...
Vedi sopra.


 MySQL e trigger) significa perdere un cliente...
Questi sono casi limite, ed è ancor più valido il discorso di *non*
appoggiarsi al db. Se una parte del lavoro del db lo dovete fare voi,
tanto vale farlo tutto...


 che continueranno a funzionare bene :)
Sicuramente il discorso vale maggiormente per un assembler...


 sai che abbiano ripreso a lavorarci sopra?
Ho letto qualcosa recentemente in un post su un qualche NG, ma non
saprei quanto questo fosse attendibile.


 che le cose vadano come ti aspetti.
Diciamo che è molto probabile (ma veramente molto) che il db queste cose
le faccia molto meglio (ma veramente molto) di come sia possibile farle
'a mano' nell'applicazione...


'a mano' nell'applicazione...
Mi ricordo quando lavoravo come dipendente nella ditta precedente gli
accidenti che volarono una volta quando un trigger che doveva scattare
in realta' rimaneva fermo... Alla fine tramite un incident aperto con
Microsoft ci fu segnalato che MS SQL 6.5 in una certa situzione
(trigger su tabelle temporanee etc etc non ricordo i dettagli) non
faceva scattare i trigger :-P
Lo riporto come aneddoto, sono un fautore di sfruttare le
caratteristiche dei server quando e' possibile.
Ciao :-)
Stefano "HappyMan" (Lago Maggiore - NO)
--
Personal Web 
http://www.sgr.info
Email happyman69 (at) 
libero.it

 caratteristiche dei server quando e' possibile.
I bug sono presenti in ogni sw... però più è utilizzato un sw più è
facile che saltino fuori e vengano corretti.


Sicuramente il discorso vale maggiormente per un assembler...
oddio, vero soprattutto concettualmente.
ok, stiamo parlando di aria fritta, ma il c e' la cosa piu' a basso
livello che si puo' considerare portabile senza tanti impazzimenti.
se scrivi in assembly, sicuramente sei zero dipendente da tutto quello
che c'e' sopra, ma l'assembly di ogni processore e' differente e la
portabilita' e' zero. ok, si potrebbe anche scrivere un assembler che
assembla l'asm-x86 su un motorola o uno sparc, ma per ora non esiste e
quindi la portabilita' di fatto e' solo concettuale.
saluti.


saprei quanto questo fosse attendibile.
capito. per conto mio, l'impazzimento di mettere su e far girare
cygwin ne vale la pena, ma per un'applicazione commerciale di solito
un server dedicato e' una spesa piu' che proponibile. anche perche' un
pc su cui far girare il tutto oggi costa anche solo 500/600 euro +
iva...


vero, ma dipende anche dal tipo di investimento.
500 euro + iva per un serverino non si possono spendere? va in
ammortamento in un anno e lo puoi mettere anche come bene di consumo:
secondo me, si puo' *sempre* spendere.
naturalmente, imho.


'a mano' nell'applicazione...
questo e' vero. ma fino a, diciamo, 50 client, riesci ad accorgerti
della differenza di prestazioni dovuta allo sfruttamento non
ottimizzato del motore? e i client si accorgono che non stanno andando
alla max velocita'?
sono curiosita': non sto dicendo che non sia cosi'.


 costruisci l'applicazione.
Ora passi da un estremo all'altro... come dicevo nell'altro messaggio, il
nocciolo della questione, perlomeno nella nostra realta', e' che "il cliente
vuole usare il *suo* DB", cosa che nella pubblica amministrazione, per
esempio, e' assai comune; se addirittura gli proponi come alternativa
sistemi poco diffusi, stai ben certo che e' un cliente perso...
Tutto quello che nei database completi e', se posso definirlo cosi',
"extra-applicativo" ci serve ed e' il benvenuto; , multiutenza, sicurezza,
server distribuiti, backup, ma fanno parte di un ottimizzazione conseguente:
hai un dababase serio che li supporta? lo usiamo. ne hai uno cosi', cosi'?
il programma gira comunque, basta sia accessibile con librerie standard (e
quindi, please, niente "easy-to-use APIs" :-))
La logica che c'e' dietro ad un trigger e', sotto sotto, molto banale:
quando fai un'operazione su una tabella, potrebbero essere coinvolte altre
tabelle, direttamente collegate o meno... tradotto in un'interfaccia ad
oggetti diventa molto semplicemente: l'applicazione chiama il metodo
Pratica.Rimuovi, la classe Pratica sa come e dove toccare il DB; la relativa
perdita' di prestazioni, nell'economia complessiva dell'applicazione, e'
irrilevante.
Io sarei il primo a fare andare un motore di dababase al 100% delle sue
possibilita', ma sfortunatamente ci sono altre esigenze da tenere in
considerazione, qundi prima di stabilire che una cosa e' senza senso o meno,
bisogna affrontare discorsi che non sono squisitamente tecnici.
Il tuo approccio, o quello di Stefano "PC client snelli, il porting me lo
paghi" e' sacrosanto, pero' nel nostro caso paga di piu' alzare i requisiti
hardware, allentare di contro quelli sofware e poter dire che certe cose le
facciamo a costo zero


 quindi la portabilita' di fatto e' solo concettuale.
Certamente, ma considera che con una nuova architettura non puoi
utilizzare compilatori C vecchi (= per altre architetture), e mentre č
possibile che ci sia un assembler per questa nuova architettura, ma non
un compilatore C, il contrario č impossibile...
Ciao, sempre parlando di aria fritta ;-)


 iva...
Certamente, mettere su un server FreeBSD con PostgreSQL sarebbe una
cosa ottima, e costerebbe sicuramente molto, molto, molto meno che non
comprarsi una licenza SQLServer od Oracle.


 sono curiosita': non sto dicendo che non sia cosi'.
Non è un discorso solo di prestazioni, ma anche di quanto sia testato il
codice, e quindi di minori o maggiori bug.


 facciamo a costo zero
Sono d'accordo con te, ma un buon design dell'applicativo ti può
permettere di utilizzare (ad un costo minore) le caratteristiche del deb
quando presenti, ed utilizzare caratteristiche personalizzate (ad un
costo maggiore) quando il db ne sia sprovvisto.


comprarsi una licenza SQLServer od Oracle.
ottenendo risultati paragonabili per numero di utenti "ragionevoli" in
ambito italiano. non so quanti abbiano migliaia di client
"contemporanei", ma credo che molti di noi lavorino con numero di
client "contemporanei" dell'ordine delle decine o poche centinaia.


 client "contemporanei" dell'ordine delle decine o poche centinaia.
Esattamente...
