Good thread, which absolutely nails the point 'dev decisions for app cases' make a developers world go round. I personally couldn't think of a greater waste of time than a benchmark comparison between client server rdbms's and sqlite. Do what benefits your case most. The above from Jim pretty much encapsulates my thoughts:
"SQLite is not directly comparable to client/server SQL database engines > such as MySQL, Oracle, PostgreSQL, or SQL Server since SQLite is trying to > solve a different problem. Client/server SQL database engines strive to > implement a shared repository of enterprise data. ...SQLite strives to > provide local data storage for individual applications and devices." > I could bang on about my own preferences and decisions I've made but they'd only be reiterating the points made above. They were based on system requirement specs and where local storage was involved it was a blindingly obvious decision to go with sqlite. Rob above made another excellent point often overlooked (usually an afterthought for many dev's): 4. The support is top notch. I have brought and paid for govt scale > databases for governments and to be honest the support for SQLite is just > as good, and to be honest I would say better than Big Red or Big Blue (and > I used to work for Big Blue). > It is another unique property of a great product. Support is not just sqlite specific either (a cop out on many a tech forum) and particularly on this list the topics can be rather broad. There is plenty of good quality feedback and many a good general SQL solution which just adds to the sqlite package as a whole. On 16 February 2016 at 09:42, Jim Callahan <jim.callahan.orlando at gmail.com> wrote: > SQLite would be most comparable to *SQL Server Express LocalDB* edition > which is introduced in this July 2011 blog post > > https://blogs.msdn.microsoft.com/sqlexpress/2011/07/12/introducing-localdb-an-improved-sql-express/ > > More uptodate information about *SQL Server Express LocalDB* edition > is in this 2016 Microsoft Developer's Network (MSDN) article > https://msdn.microsoft.com/en-us/library/hh510202.aspx > > This page "*Appropriate Uses for SQLite*" (whentouse.html) describes BOTH > "*Situations Where SQLite Works Well*" > > and > > "*Situations Where A Client/Server RDBMS May Work Better*" > http://sqlite.org/whentouse.html > > > Opening lines of whentouse.html: > > "SQLite is not directly comparable to client/server SQL database engines > such as MySQL, Oracle, PostgreSQL, or SQL Server since SQLite is trying to > solve a different problem. Client/server SQL database engines strive to > implement a shared repository of enterprise data. ...SQLite strives to > provide local data storage for individual applications and devices." > > Even Microsoft has adopted SQLite for some limited tasks (such as storing > state) within every shipping copy of Windows 10. > "SQLite is a unique case: it is an open source, externally developed > software that is used by core system components, and our flagship apps like > Cortana and Skype. ...After shipping SQLite as a system component in July, > we wanted to include it in our SDK for November. With more than 20,000 > Windows Apps and more than half of our top apps using SQLite, it made sense > to just make expose the system SQLite to app developers." > http://engineering.microsoft.com/2015/10/29/sqlite-in-windows-10/ > > > There is a historical and unfair (specially compiled version of SQLite > against default settings of PostgreSQL) benchmark > available on this page, but now that you understand the use cases, this > particular benchmark is not that useful in addition > to being out of date and unfair. > https://www.sqlite.org/speed.html > > Jim Callahan > Data Scientist > https://www.linkedin.com/in/jamesbcallahan > Orlando, FL > > On Mon, Feb 15, 2016 at 4:54 PM, Simon Slavin <slavins at bigfraud.org> > wrote: > > > > > On 15 Feb 2016, at 9:41pm, James K. Lowden <jklowden at schemamania.org> > > wrote: > > > > > SQL Server has none of those restrictions, and probably keeps pace with > > > SQLite even on its home turf. But the administration of SQL Server is > > > nontrivial. For that reason alone, I would never use it in situations > > > where SQLite would do. > > > > That's the fella. Major advantage of SQLite: zero admin. Not even a > > background task. > > > > Second advantage: you know exactly where you data is. Better still, it's > > simple: one database == one file, and the file has the same name as the > > database. I remember trying to reconstruct a MySQL database from a dead > > server. One folder with a confusing mass of files in. Your database is > > part of some of those files, but the files may be huge even if the one > > database you care about is tiny. That was not a fun time. > > > > Simon. > > _______________________________________________ > > sqlite-users mailing list > > sqlite-users at mailinglists.sqlite.org > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > -- Regards, Michael.j.Falconer.
