SQLite non è un po 'sottovalutato? [chiuso]


15

Prima di porre la domanda, vorrei prima descrivere i miei pensieri su SQLite.

Mi piace che gli strumenti siano piccoli, veloci e, soprattutto, abbiano solo la funzionalità davvero necessaria. Ecco perché mi piace SQLite e MS-SQL mi piace un po 'meno.

Ad esempio: MS-SQL può avere molte più funzionalità, scalabilità, ecc. Ecc., Ma può anche essere un problema installarlo se sei sfortunato. Naturalmente, non sto dicendo che un'installazione difficile sia un motivo per non scegliere un determinato database.

Non capirmi male: MS-SQL è un prodotto di qualità eccellente. Ho molta esperienza con MS-SQL; Capisco molto bene il prodotto come professionista. Lo preferisco meno in alcune circostanze in cui non è realmente necessario (= non molti utenti, <10-15).

Quanta funzionalità di un database usi davvero? Nella mia esperienza è spesso solo il normale SQL (SELECT, INSERT e UPDATE).

Mi piace SQLite. È affascinante e veloce. È estremamente facile da "installare". Penso che SQLite possa fare più di quanto sostiene di poter fare. Perché usarlo solo per applicazioni a singolo processo / utente singolo? Dopotutto: non molte applicazioni accedono costantemente a un database.

Ad esempio: considera un'applicazione ERP con, diciamo, 15 utenti. Perché SQLite non può essere utilizzato per questo? Ammettiamolo: nella mia esperienza professionale la maggior parte delle volte gli utenti di questo tipo di applicazione accederanno al database per circa il 5-10% del tempo totale in cui utilizzano l'applicazione. Nell'altro 90-95% stanno solo guardando le informazioni sullo schermo, inserendo i dati in una griglia / modulo e quando salvano il loro input che non è più di 1 secondo del tempo del database. Fe: 1,5 minuti di tempo di input vs. 1 secondo di tempo di risparmio.

Se il file di database SQLite viene bloccato durante il "tempo di risparmio", altri utenti che devono accedere al database attendono, ma non se ne accorgono perché il tempo di attesa sarà molto ridotto (impercettibile). Nel codice devi solo fare i conti con il possibile tempo "occupato" del database, per evitare eccezioni, ma non è difficile da fare.

Qualcuno, che deve pensare allo stesso modo di me, ha persino creato una soluzione client-server per SQLite: SQLitening . Questo mi ha reso più convinto che forse non mi sto prendendo in giro.

Naturalmente ci sono applicazioni ad uso intensivo di database in cui SQLite non si adatta. Ma ora che ci penso, molte applicazioni multiutente, se non superano i 15 utenti, dovrebbero andare bene con SQLite.

Molti dei nostri clienti non spendono molto in hardware, quindi incontro spesso un unico server con tutto (Exchange, SQL (s), client, ecc.) E per questo sono quasi "senza fiato". Se potessi consegnare un prodotto che non ha requisiti di sistema elevati, il mio cliente sarebbe felice. SQLite non aggiunge alcun peso (almeno non molto), lo fa MS-SQL. Quindi non sceglierei SQLite perché è gratuito, economico o facile da installare. Lo sceglierei per motivi pratici / tecnici.

FYI: Nella mia professione vendiamo prodotti (personalizzati e standard, principalmente ERP) a clienti in cui, in media, non più di 5-6 persone useranno il prodotto. Ci sono alcune eccezioni, ma non più di 10-15 utenti.

La domanda è: ho ragione nel pensare di poter usare SQLite per alcune applicazioni multiutente come nell'esempio che descrivo? Ci sono degli svantaggi tecnici che dovrei conoscere? Quali sono le tue esperienze (negative o positive) che mi aiuteranno a fare la scelta giusta?

Aggiornamento: non considerare questo come un giudizio negativo di altri database. Sono per lo più tutti prodotti di qualità. Sto solo condividendo i miei pensieri qui e sono interessato alle tue opinioni al riguardo.


9
Siamo spiacenti, ma aggiungendo "Ho ragione?" non trasforma un rant in una domanda.
pdr,

1
@pdr: Perché lo consideri un rant? Non sto giudicando negativamente MS-SQL o altri database; sono per lo più tutti prodotti pregiati. Sto solo condividendo i miei pensieri e sono interessato a sentire le opinioni di altri colleghi programmatori. Niente di più, niente di meno.

3
Non ci sono dubbi, solo una ricerca di convalida. Dalle FAQ: "Dovresti solo porre domande pratiche e rispondenti in base ai problemi reali che affronti. Le domande chiacchierate e aperte riducono l'utilità del nostro sito e spingono altre domande dalla prima pagina". programmers.stackexchange.com/faq
pdr

1
@pdr: lo capisco, ma onestamente intendevo fare una domanda qui. Forse non ero chiaro, quindi ho riformulato la domanda.

4
Scelta del database, ottimizzazione del codice, client, server o applicazione basata sul web, questi sono tutti aspetti da considerare e i pro ei contro devono essere discussi su una piattaforma come questa. Per me un rant è più quando qualcuno rifiuta categoricamente di trovare qualsiasi qualità di riscatto in una particolare tecnologia.
JeffO,

Risposte:


8

Ci sono molti casi in cui SQLite è abbondante. L'utente, il dipartimento o la società raramente superano di gran lunga (non ne sentiamo parlare tanto perché nessuno chiama un programmatore se l'applicazione funziona correttamente.) Potresti fare lo stesso argomento per un file MS Access (Windows) o SQL Server Compact Edition (è richiesta l'installazione). Sono tutti abbastanza buoni per un'applicazione locale perché non devi preoccuparti della sicurezza del file.

In uno scenario multiutente su una rete locale, il file andrà in una cartella condivisa che dovrà accedere a tutti gli utenti: chiamare la sicurezza. La semplice manutenzione o eventuali modifiche alla struttura della tabella come i backup o l'aggiunta di una colonna impediranno l'accesso ad altri utenti. Ieri sera il backup non ha funzionato perché qualcuno ha dimenticato di uscire dall'applicazione. Cosa succede quando vuoi fare un backup a metà giornata? Tutti razionalizzano di non aver bisogno di alcun backup durante il giorno a causa delle limitazioni tecniche del loro database. Ad un certo punto, l'installazione di SQL Server Express / altro equivalente sul server richiederà alcune impostazioni iniziali e la configura- zione della sicurezza, è più complicato in anticipo, ma sarà necessaria poca manutenzione.

C'è sempre la preoccupazione per la scalabilità / ingegneria eccessiva. Anche se il numero di utenti o la quantità di dati è ancora gestibile, qualcuno ha sempre l'idea di utilizzare i dati in tempo reale su alcune intranet o altre interfacce di siti Web / browser. I database di file presentano problemi. Ci vuole solo una persona che vuole accedere al file di dati tramite una VPN (l'app è installata sul proprio laptop) per darti un problema di "ridimensionamento". Puoi creare l'app per consentire agli utenti disconnessi che possono sincronizzarsi al loro ritorno. Semplicemente non ne vale la pena per gli utenti occasionali fuori sede.


Potresti fare lo stesso argomento per SQL Server Compact Edition, ma non per un database MS Access. I database di accesso sono trattati come se fossero un vero database, ma funzionano più come file condivisi. Sono una soluzione fragile; SQL Server Compact è in realtà un'alternativa migliore, più veloce e più affidabile che funziona ancora con i frontend di Access. Sospetto che SQLite sia sostanzialmente più resistente di un database di Access, anche se tecnicamente è una soluzione di file condivisa.
Robert Harvey,

@RobertHarvey - Abbiamo esigenze aziendali in cui MS Access è stata una soluzione abbastanza buona (cioè migliore di Excel) per 10 anni. Quando viene fatto un grosso affare, dobbiamo avere qualcosa in funzione. Gli utenti esperti con competenze di accesso sono molto più facili da trovare e sfruttare. La funzionalità deve essere disponibile entro una certa data, ma siamo fortunati che scalabilità, prestazioni, crescita dei dati e sicurezza non siano mai stati un fattore. Aggiornamento di Access, questa è un'altra storia.
JeffO,

Non fraintendetemi; Penso che l'accesso sia fantastico. Ma SQL Server Compact sarebbe il mio requisito di backend minimo per qualsiasi nuova applicazione di Access in cui gli utenti condividessero i dati.
Robert Harvey,

@RobertHarvey - Dovrò esaminarlo. Grazie
JeffO

12

Penso che sia fantastico da usare quando è necessario un database "interno". Cioè, un database con il quale l'applicazione / codice interagirà ma che non sarà direttamente correlato al motivo principale per cui l'applicazione esiste. Invece di utilizzare enormi mapping in memoria o gestori di cache, è possibile utilizzare ad esempio un database di questo tipo. Ne ho un esempio molto concreto, visto che l'ho usato di recente nei casi di test JUnit / DBunit in cui dovevo collegarmi a un database, eseguire alcuni lavori, leggere i dati e cancellare tutto alla fine. Dal momento che è sufficiente creare un file vuoto per creare il database , è stato abbastanza facile da fare.

Un altro utilizzo che vedo: quando hai un solo utente. Sì, è possibile, pensa ad esempio "Firefox" o "Opera" :-)

Inoltre, sul sito Web di SQLite ne sono molto onesti e spiegano quando NON UTILIZZARLO (vedere il paragrafo "Situazioni in cui un altro RDBMS può funzionare meglio")

ps: correlato ai commenti su SQL Server Express, sì, deve essere "installato". E ho avuto qualche problema ad aggiornarlo personalmente (ho dovuto rimuovere manualmente alcune chiavi di registro relative alla versione precedente per poter installare il 2008 R2). Tuttavia, se si desidera confrontare SQLite con un database sviluppato da Microsoft, consultare SQL Server Compact Edition , che non è necessario installare (consultare "distribuzione basata su file privati").


Ho esaminato CE, ma in qualche modo sembra che SQLite sia migliore / più veloce / più facile. Non lo so per certo, non ho usato / testato CE abbastanza per esserne sicuro.

5

Ad esempio: considera un'applicazione ERP con, diciamo, 15 utenti. Perché SQLite non può essere utilizzato per questo?

Pochissime applicazioni hanno per sempre pochi utenti. E per tutto ciò che vede più utenti e una manipolazione dei dati più complessa, l'utilizzo di SQLite è completamente fuori discussione per motivi di prestazioni a causa del semplice modello di blocco "una transazione di scrittura alla volta".

Supponiamo che tu abbia 100 utenti, ognuno dei quali lavora per 60 secondi compilando un modulo e quindi inviandolo. Quindi è necessario elaborare circa 1,6 transazioni al secondo. Il modello di dati è complesso e il salvataggio di un modulo comporta la lettura e la scrittura su molte tabelle di grandi dimensioni, forse anche comunicando con un sistema diverso, quindi ogni "modulo di invio" comporta una transazione che richiede 2 secondi. Ma SQLite non può elaborare le transazioni contemporaneamente, quindi questo significa che può elaborare solo 0,5 transazioni per scond. Ops.

"Può essere una seccatura da installare" non è una buona ragione per decidere contro un'infrastruttura critica. Inoltre, ci sono altri motori DB tra cui scegliere, almeno due dei quali (MySQL e Postgres) sono gratuiti e non hanno i limiti di concorrenza di SQLite. Potrebbero anche essere più facili da installare rispetto a MS-SQL.


Capisco e sono d'accordo. Ma nella mia professione non ho davvero clienti che usano i nostri prodotti (standard e personalizzati, principalmente ERP) con più di 10 persone. In media sono anche 5-6 utenti. Riformulerò la mia domanda.

4
@Marcus V: La domanda è: se un cliente è cresciuto molto e scopre che l'app che hai creato diventa incredibilmente lenta da usare, e tu dici loro il motivo è che il DBMS non può gestire così tanti utenti e loro chiedono " perché non hai usato un DBMS migliore ", come pensi che la risposta" quelli sono difficili da installare "sarebbe stata ricevuta? Posso dirti quale sarebbe la mia reazione: penserei "questo è un dilettante. Devo trovare qualcun altro per scrivere il mio software".
Michael Borgwardt,

Hai ragione. Non penso che intendessi in questo modo, ma posso assicurarti che non sono un dilettante. Sicuramente userò sistemi DBMS "reali" se la situazione lo chiedesse. I nostri prodotti sono concessi in licenza per un numero di utenti. Svilupperei usando SQLite solo se sapessi che il numero di utenti è relativamente piccolo (<10-15). Se il cliente superasse un limite, che nella nostra base clienti non accadrà presto, possiamo sempre convertirlo relativamente rapidamente / semplicemente in un altro database. Questa non è scienza missilistica;). Sulla base delle tue osservazioni, ho riformulato la domanda per renderla più chiara.

L'utente che piange male per aver superato l'applicazione è stato probabilmente informato delle limitazioni dell'utente ma ha scelto di percorrere la strada più economica. Va tutto bene nella configurazione iniziale, ma quanto saranno felici quando dovrai addebitare loro un'altra commissione per l'installazione sul nuovo server, quando avrebbero potuto semplicemente copiare un file?
JeffO,

1
@Jeff O: Immagino tu abbia frainteso le mie intenzioni. Sto Non scegliere SQLite perché è gratis, a buon mercato e / o facile da installare. Lo sceglierei solo perché è piccolo, veloce e rispettoso delle risorse. Quindi è principalmente per motivi pratici / tecnici. Molti dei nostri clienti non spendono molto per l'hardware, quindi incontro spesso un unico server con tutto (Exchange, SQL, ecc.) E per questo sono quasi "senza fiato". Se potessi consegnare un prodotto che non ha requisiti di sistema elevati, il mio cliente sarebbe felice. SQLite non aggiunge alcun peso, MSSQL lo fa.

4

Penso che SQLLite sia eccellente per lo sviluppo di applicazioni, la sua più grande forza è che non ha bisogno di essere installato sul client.

Tuttavia, non sottovalutare neanche SQL Server Express, è un eccellente database gratuito con la maggior parte delle funzionalità del normale server sql con solo una limitazione delle dimensioni del database (che è difficile da superare) insieme alla capacità di utilizzare gli strumenti eccellenti del normale server SQL.

Il più grande svantaggio di afaik è che è necessario installarlo, ma sono un po 'incerto di quella parte, potrebbe essere un modo per aggirarlo ora


2
Hai ragione. MS-SQL Express è un prodotto di qualità eccellente. È solo che lo trovo un po 'gonfio e utilizzo troppe risorse. Al giorno d'oggi PC / server non è un problema. Sono solo una persona di vecchia scuola che pensa ancora che hardware più potente non significhi che dovrei trascurare / sprecare risorse se posso evitarlo. Meno meglio ...;).

2
il database con motori DB può optare per ottimizzare l'accesso memorizzando nella cache la memoria anziché leggere / scrivere dai dischi. Ma non sono sicuro delle prestazioni per DB in-process come SQL Lite
sarat

1
@sarat: Afaik SQLite utilizza intensivamente le cache di memoria.

2

Non considero SQLite come un database serio se hai a che fare con pochi GB di dati ogni ora. Diventa dolorosamente lento e riduce le prestazioni dell'intera applicazione. Scusa, ma non sono d'accordo con il tuo fascino per SQLite :-)


1
Rispetto la tua opinione. Sono solo un uomo pratico. Quando scelgo uno strumento lo scelgo perché penso che sia la decisione più realistica / pratica. Non sono affascinato da SQLite, ma ammiro il modo in cui sono riusciti a mettere così tanto in un pacchetto così piccolo, efficiente e veloce. Come ho detto nella mia domanda: se MS-SQL è uno strumento migliore per un determinato lavoro, lo sceglierei semplicemente. Ma, come ho spiegato, in molte occasioni credo davvero che SQLite si adatta perfettamente.

Quell'abbondanza di utilizzo dei dati è un grande if.
JeffO,

@Jeff O: Giusto. Sceglierei SQLite solo se il numero di utenti è relativamente basso (<10-15) e anche la quantità totale di dati non è elevata. Nella nostra esperienza, la dimensione totale del database è spesso di 300-400 MB e quasi mai> 1 GB.

1

Il problema con i database è che tendono ad accumulare sempre più dati. La scelta di un DB leggero comporta il rischio che il tuo strumento non si ridimensioni correttamente.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.