Gambas-it
Archivi (sola lettura) => Domande tecniche (Gambas 2) => Topic aperto da: Taurus dei miracoli - 11 Gennaio 2011, 22:52:20
-
io ho 2 progetti in Gambas2 con db mysql.
vorrei trasformarli con db sqlite3.
come fare?
come riuscire a cambiare il db e il codice?
???
-
devi solo cambiare il database o portarti anche i dati?
-
Devo trasferire anche i dati dal formato mysql al formato sqlite.
-
fai un programmino che legge i dati da mysql e li scrive su sqlite
-
Ci avevo pensato, ma ora devo vedere come fare a gestire 2 connessioni.
Ci provo e poi, al limite, vi rompo nuovamente.
Grazie :2birre:
-
Puoi fare benissimo 2 conessioni e fare una query che travasa i dati
-
Puoi fare benissimo 2 conessioni e fare una query che travasa i dati
Si, lo immaginavo.
Poi provo.
Grazie
-
magari potresti fare un prog generico che copia la struttura da mysql e genera un database sqlite così potrebbe essere utile a tutti
-
io ho 2 progetti in Gambas2 con db mysql.
vorrei trasformarli con db sqlite3.
come fare?
come riuscire a cambiare il db e il codice?
???
la soluzione piu' veloce? esporta i dati da mysql in formato sql e caricali in sqlite
-
Solo una curiosità: come mai vuoi passare da MySQL a SQLite?
-
Per due motivi:
1) il db non deve essere aggiornato ma solo consultato;
2) per la portatilità immediata del db sqlite3;
Inoltre devo dire che ho trovato maggiore supporto esterno (di software) per manipolare sqlite3 che mysql. :coder:
Poi bisogna anche provare a cambiare ogni tanto. ;D
-
Ho creato la procedura per trasformare il mio db da mysql a sqlite3.
La allego a questo post.
:coder:
-
Chiedevo non perché reputi SQLite un DB scarso quanto perché è limitato al fatto che serve in genere solo se hai pochi dati da gestire e se la gestione è limitata al solo utente locale.
Magari ora reputi che SQLite sia giusto ma fra un po' potresti accorgerti delle sue limitazioni. Tutto qui.
-
Ciao Leo, per esempio io devo costruire una app per iPhone che legga dei dati da db da cui attinge un sito internet in php. E iPhone supporta solo SQlite... :)
-
In realtà quello che non si capisce è il motivo vero della conversione mistica.
Tra MySQL e SQLite le differenze non sono, come affermato anche da Leo, a livello di quantità dati, quando al fatto che MySQL è un RDBMS, quindi è predisposto per applicazioni client-server, anche se poi viene utilizzato sullo stesso nostro pc.
Riguardo ad applicazioni stand-alone, ad esempio visualizzare un elenco comuni, o un archivio di sola lettura semplice, molte applicazioni si appoggiano a db locali, altrettanto stand-alone, senza tutta la parte che si occupa di gestire processi, utenze, e quant'altro... insomma un RDBMS. Al contrario SQLite non ha un processo attivo, ma fornisce solo una modalità di memorizzazione dati, possibilmente molto simile allo standard sql.
In questo caso, mi sembra inutile, oltre che fuori luogo, utilizzare un db megagalattico per accedere a semplici dati, soprattutto se questo viene fatto esclusivamente dalla nostra applicazioncina.
Come ho scritto spesso, non considero SQLite un database, ma sicuramente può essere utile come alternativa ad un semplice file, visto che ha già incluse alcune funzionalità sql-like.
Questo rende veloce fornire un prodottino, senza dover necessariamente installare server inutili...
-
Come ho scritto spesso, non considero SQLite un database, ma sicuramente può essere utile come alternativa ad un semplice file, visto che ha già incluse alcune funzionalità sql-like.
Questo rende veloce fornire un prodottino, senza dover necessariamente installare server inutili...
Condivido, anche se non definirei "prodottino" un programma di consultazione dati o di manipolazione in stand-alone.
Penso che, fortunatamente, abbiamo risorse diverse per la manipolazione dei dati e questa cosa dobbiamo considerarla una ricchezza anzichè un limite o... un motivo di "divisione" che non ho visto in nessuna situazione all'interno di questo forum
;D
-
non considero SQLite un database
un affermazione del genere secondo me è offensiva nei confronti di chi ha sviluppato e sta mantenendo il progetto SQLite ! :bad:
SQLite E' un database con le sue particolarità , le sue proprietà i suoi limiti e anche i suoi pregi
mi sembra anche scorretto sconsigliare a priori sqlite (mi riferisco ad altri post e altri utenti), visto che in moltissime situazione è uno strumento utile e vantaggioso.
non vi farebbe incavolare se qualcuno scrivesse che non considera Gambas un linguaggio di programmazione solo perchè rispetto ad altri linguaggi presenta alcune mancanze?
Ps: scusate il piccolo sfogo ma visto che sqlite è stato il mio primo db che ho utilizzato, ci sono affezzionato.
:2birre:
-
SQLite E' un database con le sue particolarità , le sue proprietà i suoi limiti e anche i suoi pregi
Io uso mysql che "preferisco", ma uso anche sqlite per spostare qualche dato o fare prove. Anche se uso e preferisco mysql, sqlite è indispensabile
-
Beh, fsurfing. Dai, md* mica ha detto che domani viene a casa tua a metterti Win+.NET :-*
Anch'io ho usato SQLite ma sono poi passato a MySQL. Che sia un buon prodotto lo dimostra anche Mozilla Foundation che lo usa come DB per i dati del suo Firefox. Insomma, può arrivare a gestire centinaia di MB di dati, ma non per questo è veloce e "serio".
Proprio su questo forum si è spesso parlato dei grossi limiti di questo DB, sul come tratta i dati come vuole lui (tutti TEXT che poi "rivende" all'utente in pseudo-formati differenti) ecc....
-
@Golia
Sono d'accordo su sqlite, per gambas è un partner ideale, mi piacerebbe soltanto avere un db designer all'altezza, nativo linux (se lo conoscete fatemi un 'fischio!!)
-
Per andy:
pgDesigner2 è la risposta.... lo trovi su sourceforge, ma è ancora in fase di sviluppo, anche se completamente funzionante...
Per fsurfing:
Perdona, ma a volte i concetti è difficile spiegarli e farli capire nel loro vero senso.
Io non denigro sqlite, solo che è necessario fare una netta distinzione tra un rdmbs vero e proprio, e uno strumento come sqlite che offre alcune funzionalità simil-sql. SQLite ha i suoi limiti, e forse è anche stata una scelta dello/degli sviluppatori, e và benissimo così. Io a suo tempo usavo anche il DB3plus, che era più o meno la stessa cosa, ma senza sintassi sql, e l'ho usato per parecchio tempo.
Quello che intendevo in realtà, è che l'uso di uno strumento, piuttosto di un'altro, dipende da quello che uno deve fare e che vuole ottenere.
Facendo un esempio: io uso e ho usato molte applicazioni, in alcuni casi molto complesse, che trattavano dati. Alcune di queste avevano, per esigenze di velocità e/o praticità e/o per scelta, un database interno, a volte proprietario, a volte no, ma sicuramente con dei limiti (non erano rdbms i realtà). Questo permetteva il trasporto da una macchina all'altra, ed evitava la necessità di installare un db ad-hoc (es. Oracle), il che semplificava di molto la gestione. E' ovvio che questo tipo di approccio aveva i suoi limiti, ma per le necessità intrinseche dell'applicazione andava più che bene.
Ora, da quello che ho capito nelle intenzioni di Taurus, ovvero creare un'applicazione gestionale portabile, penso sia fuori luogo portarsi appresso un server rdbms, per cui la scelta migliore potrebbe essere proprio sqlite, snello, facile, e non oneroso, oltre al fatto che non necessità di attivazione di servizio server, e via dicendo. E' ovvio che se questi non sono i requisiti richiesti, oppure le esigenze sono di espansione, potrebbe essere che sqlite non sia alla fine all'altezza della situazione, per la scelta dovrà essere fatta su altri.
Come ultimo, una volta che si decide di usare un rdbms, tra MySQL e PostgreSQL (rimanendo in ambito open-source), ci sono delle differenze sostanziali. Da una parte MySQL offre maggiore velocità a discapito di tutta una serie di cose che, in ambiente enterprise necessitano. PostgreeSQL si mantiene nello standard SQL-97, è potente, offre tutte le caratteristiche presenti nei database commerciali di classe enterprise, e tratta anche dati di dimensioni enormi. La differenza di velocità tra i due diventa poi insignificante quando si arriva appunto su quantità di dati pesante e, alla fine PostgreSQL ne esce unico vincitore.
Questo è in sintesi lo stato attuale delle cose.
Come ultimo: io non ho mai denigrato sqlite, come schifo di applicazione, ma che ha dei limiti, evidenti e che quindi non dobbiamo lamentarci che certe cose non funzionano come uno pensa. Già il trattamento dei tipi base è molto semplice, e nelle applicazioni bisognaa tenerne conto.
Bè ora termino qui, anche perchè non vedo più l'editor (malefica Explorer...)
-
Scusate, non volevo mettere in moto tutto questo popo' di discussione (anche se, leggendo tutto con attenzione credo di conoscere l'argomento molto più di prima).
La mia riflessione mi ha portato alla consapevolezza che, forse, la progettazione sia ancora alla base di una buona applicazione (e mi viene in mente anche la discussione aperta da Ceskho sull'interfaccia grafica del suo programma).
Tutto questo è veramente utile...
...ed il bello di questo forum è che ho trovato persone che sono intenzionate a dare il meglio perchè tutto il movimento cambi in meglio.
:2birre:
-
Io amo sqlite perchè la gente ama sqlite.... :)
Sqlite ti permette di dare alla gente un programma che 'funziona da solo' senza dover installare e configurar nulla. Apprezzo molto il discorso della "scelta del programmatore"...secondo me stiamo discutendo su due prodotti simili ma diversi.
Tanto per dirne una: anche un piatto di pasta al forno e un pacco di crackers sono da considerarsi cibo. Entrambi vanno mangiati ed entrambi ti saziano ma una è più difficile da prepare anche se ti sazia prima mentre l'altra è più semplice da consumare ma necessita di più tempo per raggiungere il suio fine.
La scelta sta a chi mangia..... ;)
E dopo questa perla di saggezza vado a sviluppare meganalotto che sqlite mi aspetta.... ;D
-
Tanto per dirne una: anche un piatto di pasta al forno e un pacco di crackers sono da considerarsi cibo. Entrambi vanno mangiati ed entrambi ti saziano ma una è più difficile da prepare anche se ti sazia prima mentre l'altra è più semplice da consumare ma necessita di più tempo per raggiungere il suio fine.
La scelta sta a chi mangia..... ;)
E dopo questa perla di saggezza...
E' evidente che è la perla di saggezza dell'ora di pranzo :ciao:
-
Certo che 'sto ceskho, se non ci fosse, toccava crearlo... :P
Io penso che le cosiddette "perle di saggezza" provengano più dalla "panza" che da qualcos'altro...
Stavo pensanso al confronto tra "piatto di pasta" e "crackers"... ma che razza di paragone è? A me, prima di arrivare al piatto di pasta, avoja di cracker... :D
Scherzi a parte, spero che i miei chiarimenti su sqlite siano stati stavolta compresi...
-
@mdxxxx
non sapevo che pgDesigner funzionava anke con sqlite, grazie x l'info :2birre: