Sqlite per config e simili, stato attuale degli hosting

[Uno]

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?

[andrea.paiola]

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:

• MS SQL Server (PDO) — Microsoft SQL Server and Sybase Functions (PDO_DBLIB)
• Firebird/Interbase (PDO) — Firebird/Interbase Functions (PDO_FIREBIRD)
• IBM (PDO) — IBM Functions (PDO_IBM)
• Informix (PDO) — Informix Functions (PDO_INFORMIX)
• MySQL (PDO) — MySQL Functions (PDO_MYSQL)
• Oracle (PDO) — Oracle Functions (PDO_OCI)
• ODBC and DB2 (PDO) — ODBC and DB2 Functions (PDO_ODBC)
• PostgreSQL (PDO) — PostgreSQL Functions (PDO_PGSQL)
• SQLite (PDO) — SQLite Functions (PDO_SQLITE)
• Driver 4D for PDO — Driver 4D for PDO (PDO_4D)

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

[Kuro]

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?)

[Uno]

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

[guest]

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.

[TheVice]

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.

[Uno]

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....

[Uno]

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).

[TheVice]

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)

[Uno]

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....

[andrea.paiola]

sinceramente la scelta di sqlite mi pare la più sfortunata: o lasci su filesystem o metti su MySQL... anche se sono configurazioni che cambiano raramente personalmente metterei su MySQL

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

pensi che sqlite non pesi sulle risorse del server? pesa pesa

[guest]

pensi che sqlite non pesi sulle risorse del server? pesa pesa

Non avendo un demone costantemente in esecuzione, per quanto pesante che possa essere, sqlight sarà sempre una frazione di mysql.

[Uno]

Non avendo un demone costantemente in esecuzione, per quanto pesante che possa essere, sqlight sarà sempre una frazione di mysql.

Infatti...
Se uso mysql devo passare per l'interprete php e questo si collega al dbms di mysql il quale deve poi tirare fuori quello che mi serve.

Se ho bisogno di query particolari (come nei contenuti dinamici) è un discorso e il gioco vale la candela, ma singole variabili sempre uguali per lungo tempo.....

Se uso sqlite da una parte è come usare fopen, cioè passo solo per php, dall'altra siccome invece che usare il parser generico di file di php, usa l'estensione specializzata per leggere determinati campi tramite sql, dovrebbe (ma qui dico ad intuito, non ho in mano benchmark) essere perfino più leggero che scrivendo e leggendo su file normali.

[andrea.paiola]

Non avendo un demone costantemente in esecuzione, per quanto pesante che possa essere, sqlight sarà sempre una frazione di mysql.

ma tanto mysql ce l'ha in esecuzione in ogni caso
con la cache attiva inoltre il carico aggiuntivo è praticamente nullo

[TheVice]

Sqlite come engine db è: performante, leggerissimo e altamente integrabile.
Lì dove occorre una gestione locale o una semplice gestione di file è indicatissimo.
Avere 2 engine in esecuzione ? SQLite è on demand mentre MYSQL è sempre in idle con le risorse perennemente allocate. Per piccole cose MYSQL è un macigno. In più anche sqlite garantisce l'integrità transazionale. Il che non è poco.
Unico neo l'accesso concorrente al DB. In python ho avuto un po' di difficoltà ma non usavo sqlalchemy e son ancora niubbo del linguaggio e del framework. In C++ nessun problema.
E calcola che in C++ lo uso per un'applicazione attualmente in sviluppo che lancia svariate query sql quasi ogni 8 secondi. Serve a completare il feedback di un braccio meccanico e dei suoi sensori.
Poi se metti il db in memoria è un fulmine!