Jump to content
Sign in to follow this  
Uno

Sqlite per config e simili, stato attuale degli hosting

Recommended Posts

Ciao ragazzuoli,

sto sviluppando una nuova applicazione in php e pensavo di mettere in sqlite tutti i dati di configurazione che potrebbero essere cambiati ma neanche così spesso.

 

Mi chiedevo una cosa. Per ora l'applicazione è ad uso interno, ma potrei decidere di darla in futuro (free o ad un prezzo abbordabile).... come è la situazione degli hosting riguardo sqlite?

Teoricamente dovrebbero essere tutti (od iniziare ad essere) con php5 e quindi supporto nativo, ma se non viene abilitato sul php.ini....

 

Insomma volendo cedere l'applicazione è un rischio usare sqlite e mi conviene rimanere sui soliti file?

Share this post


Link to post
Share on other sites

beh con PHP 5, se usi come dovresti PDO e SQL standard... dovresti riuscire a rimanere indipendente dal database e quindi la tua applicazione girerà con i database supportati da PDO:

 

 

detto questo, ovviamente se è fattibile avere sti dati su file di testo... non avrai bisogno di alcun db ^^

Share this post


Link to post
Share on other sites
Insomma volendo cedere l'applicazione è un rischio usare sqlite e mi conviene rimanere sui soliti file?

beh teoricamente una soluzione indipendente dal database ti assicura minori problemi di "compatibilità" con le configurazioni dei vari provider. Ma dovresti valutare se è conveniente sotto gli altri aspetti.

qual'è la mole di dati che devi gestire? quante letture/scritture devi eseguire ad ogni esecuzione? ecc...

 

Se decidi di usare un db, è consigliabile (come suggerito da Andrea) utilizzare pdo. A maggior ragione se utilizzi sqlite (sqlite 3 ti dice nulla?)

Share this post


Link to post
Share on other sites

Non si capisce bene quello che intendevo, colpa mia.

 

Per la parte più sotto sforzo intendo usare mysql che è praticamente trovabile ovunque, però stavo pensando all'uso di sqlite per una parte che normalmente viene fatta in due modi: o con l'uso di file o sul db normale (tipo mysql) ma con cache sul filesystem.

 

Se io invece uso sqlite per questa parte (per capirci potrebbero essere i template modificabili online, varie config etc...) mi risparmio di "cachettizzare" perchè per un uso del genere sqlite è velocissimo, non mi servono select e join complicati, ma solo pescare un singolo record.

 

Capirete che per quanto io usi sempre librerie (sono comode, ottimizzate etc) che rendono l'applicazione indipendente dal db se per i motivi spiegati volessi usare proprio e solo sqlite per determinate cose sono legato dalla sua diffusione negli hosting. Da quello che ho visto, con una piccola indagine, mi pare che non sia tanto supportato, peccato

Share this post


Link to post
Share on other sites

Secondo me, se hai comunque un database nella tua applicazione, ha poco senso creare un altro database, con un altro engine, solo per la config.

Se la tua applicazione necessita già di suo di MySQL, butta li dentro anche la config no?

Meno casini anche in fase di manutenzione del programma.

Share this post


Link to post
Share on other sites

Secondo me per sqlite3 php può anche avere dei seri limiti. In python ad esempio i db non sono accessibili in multithreading ma devi avere un solo thread di accesso esclusivo al db. In realtà questo è un limite di sqlite che è basato molto più sulle policy di lock del file fisico del db che sulle gestioni di accesso tipiche di un RDBMS. Un limite di cui tenerne conto . Io lo sto usando per un progetto in C++ e per i miei scopi direi che è ottimo. Ma vale la pena usarlo se hai un buon wrapper per la dll oppure se lo inglobi nel tuo progetto in maniera statica. In tal caso, nell'uno come nell'altro caso, non esistono limiti dovuti a ciò che ti fornisce l'hoster.

Leggendo l'uso che ne devi fare l'unico limite potrebbe essere la concorrenza di accesso sul DB.

In python c'è sqlalchemy che wrappa tutto in modo superbo, in PHP non saprei ma se l'interfaccia PDO è standard dovresti interfacciarti senza pensare troppo a ciò che ti offre l'hoster.

Share this post


Link to post
Share on other sites
Secondo me, se hai comunque un database nella tua applicazione, ha poco senso creare un altro database, con un altro engine, solo per la config.

Se la tua applicazione necessita già di suo di MySQL, butta li dentro anche la config no?

Meno casini anche in fase di manutenzione del programma.

 

Per la manutenzione del programma non c'è nessun problema.

Comunque, si, posso usare i soliti file di configurazione e le varie cartelle per i template etc....

Però volendo modificare qualcosa a caldo ed online lasciare file accessibili in scrittura non mi garba tanto (anche se si possono proteggere in molti modi), comunque è sicuramente più semplice editare dei record su db, che modificare un file... poi tutto si fa...

Insomma mi pareva un sistema facile per avere configurazioni, template ed altro facilmente editabili senza dover usare tante cache (sqlite lavora come fopen ,ma ha tutta la sua bella gestione sql).

Insomma avrei messo tutta la parte statica (ma editabile una volta ogni morte di Papa) su sqlite e tutta la parte dinamica su Mysql (o altro a scelta usando la libreria ad alto livello tipo pdo).

Non mi sembrava una cattiva idea, ma vale finchè la uso per me sul mio server dove faccio come voglio, se poi su uno shared non si può usare....

Share this post


Link to post
Share on other sites
Secondo me per sqlite3 php può anche avere dei seri limiti. In python ad esempio i db non sono accessibili in multithreading ma devi avere un solo thread di accesso esclusivo al db. In realtà questo è un limite di sqlite che è basato molto più sulle policy di lock del file fisico del db che sulle gestioni di accesso tipiche di un RDBMS. Un limite di cui tenerne conto . Io lo sto usando per un progetto in C++ e per i miei scopi direi che è ottimo. Ma vale la pena usarlo se hai un buon wrapper per la dll oppure se lo inglobi nel tuo progetto in maniera statica. In tal caso, nell'uno come nell'altro caso, non esistono limiti dovuti a ciò che ti fornisce l'hoster.

Leggendo l'uso che ne devi fare l'unico limite potrebbe essere la concorrenza di accesso sul DB.

In python c'è sqlalchemy che wrappa tutto in modo superbo, in PHP non saprei ma se l'interfaccia PDO è standard dovresti interfacciarti senza pensare troppo a ciò che ti offre l'hoster.

 

Si sono d'accordo, sul web non lo userei mai per sostituire un mysql o simili, però per usarlo al posto di fopen (in sintesi è questo il discorso) che come dicono anche sul sito di sqlite è il miglior uso, mi pareva bene, dandomi più facilità di editing.

Il problema è che è supportato nativamente dal php5 in poi ma non è attivato automaticamente, va attivato sul php.ini e non tutti lo fanno (anzi ho visto un pò in giro e diversi hoster non lo attivano).

Share this post


Link to post
Share on other sites

guarda, se usi PDO e con questo hai i permessi per caricare ed eseguire la dll di sqlite3 allora puoi:

1) standardizzare l'interfaccia al db perchè PDO è usabile sia con mysql che con sqlite (di base cambi a solo la stringa di connessione al db)

2) rendere l'applicazione meno legata a specifiche versioni di sqlite (ti basta cambiare la dll)

3) se vuoi passare a mysql non devi riscrivere il mondo ma tenere in un file xml o quel che vuoi la stringa di connessine al db.

 

A mio avviso devi solo valutare l'impatto fisico del threading sul file sqlite per evitare brutte sorprese. (Io non ne ho avute ancora ma è da mettere seriamente in conto)

Share this post


Link to post
Share on other sites
guarda, se usi PDO e con questo hai i permessi per caricare ed eseguire la dll di sqlite3 allora puoi:

1) standardizzare l'interfaccia al db perchè PDO è usabile sia con mysql che con sqlite (di base cambi a solo la stringa di connessione al db)

2) rendere l'applicazione meno legata a specifiche versioni di sqlite (ti basta cambiare la dll)

3) se vuoi passare a mysql non devi riscrivere il mondo ma tenere in un file xml o quel che vuoi la stringa di connessine al db.

 

A mio avviso devi solo valutare l'impatto fisico del threading sul file sqlite per evitare brutte sorprese. (Io non ne ho avute ancora ma è da mettere seriamente in conto)

 

Il problema non passare in caso a mysql o altri, ma che se tengo i template su mysql non metto una query per ogni pagina che carico, minimo metto il template in cache su file system, se il template lo butto dentro sqlite il problema non sussiste.

Quindi se imposto l'applicazione in un certo modo non posso solo cambiare il db, ma ci sono anche altre cose....

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×