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.