SQLite should be the default way someone manages information on a binary data file, as opposed to just inventing your format from scratch.
I remember on uni when we started defining our own formats, to later on learn about what goes inside a DBMS, and thinking, "Why on earth would I ever do the first thing again?" (not that there's no space for it, but it's not so big).
Also, when I've found a couple of times that a file that I thought had a proprietary binary format was a SQLite file, it was bliss. So much easier to navigate, inspect and work with that a huge XML file or a plain text one.
I think this is somewhat incomplete information, and I say this as a SQLite lover. It depends on your type of data, but both HDF5 and SQLite are more than adequate formats for data, and you should be using one of them.
I think HDF5 is actually a better format for long term data management, but I think SQLite is a easier to use in everyday life. There's also Parquet and Avro for these as well.
High-Energy physics also has the "code is the documentation" clusterfuck known as ROOT files.
> Miscellaneous micro-optimizations result in 22.3% more work for the same number of CPU cycles relative to the previous release. SQLite now runs twice as fast as version 3.8.0 and three times as fast as version 3.3.9. (Measured using cachegrind on the speedtest1.c workload on Ubuntu 14.04 x64 with gcc 4.8.2 and -Os. Your performance may vary.)
SQLite is amazing. It is a tech that no programmer should be unfamiliar with. It takes at most a day or two of playing with it to learn all of its various quirks and tricks, is easy to bake in to any project regardless of language, and performs like mad.
When I was tinkering with http://thredis.org I spent a lot of time looking into SQLite internals, and it is by far the most polished, comment-rich code base that I have ever seen, it reads like a fun book. Especially if you're interested in low-lever relational db stuff - how SQL statements are processed, data is stored, B-Trees, etc. It's better than any book out there (and such books tend to be very expensive).
I'd like to see the same speed measurements done for mobile. A 64-bit Linux desktop isn't representative of the #1 use case for SQLite as a mobile database replacement for Core Data.
I've never worked with Core Data, but I assume it always uses the SQLite version that ships with iOS (as opposed to a version you ship with your app), so that means that you wouldn't see these improvements on iOS for at least a year or so anyway, or am I wrong about this?
>I'd like to see the same speed measurements done for mobile.
While not exactly what you are looking for I can understand the sentiment. SQLCipher provides a project to time the performance of queries when run against standard SQLite vs. SQLCipher on iOS.
SQLite is one of the rare examples of very elaborate implemented software that is very good maintained, too.
One of the best pieces of free software around.
Where else do you find software, that was very good implemented from the beginning and is so carefully enhanced and optimized? (And not only for new "features") -- I remember no official available example.
We use SQLite extensively in Minuum and I couldn't be happier. It's in all our critical real-time code paths that bring up candidates while you're typing. Because we're on SQLite our predictions keep getting faster for free!
Faster predictions mean we can handle more types of errors (more missed characters, more complex typos) in the same time budget. Thanks SQLite, you guys are awesome.
One of the great things about SQLite is its incredibly comprehensive automated test suite. That allows aggressive optimization without fear you're breaking something.
I still remember when Firefox switched to using SQLite for most of its internal data. It felt like it took 3 or 4 releases to work out the concurrency and blocking issues. I remember back in the day it had lots to do with fsync.
Has most of that been worked out between SQLite and newer Linux kernels, or is that a pit waiting for other applications that go the same route?
[+] [-] harperlee|10 years ago|reply
I remember on uni when we started defining our own formats, to later on learn about what goes inside a DBMS, and thinking, "Why on earth would I ever do the first thing again?" (not that there's no space for it, but it's not so big).
Also, when I've found a couple of times that a file that I thought had a proprietary binary format was a SQLite file, it was bliss. So much easier to navigate, inspect and work with that a huge XML file or a plain text one.
[+] [-] batbomb|10 years ago|reply
I think HDF5 is actually a better format for long term data management, but I think SQLite is a easier to use in everyday life. There's also Parquet and Avro for these as well.
High-Energy physics also has the "code is the documentation" clusterfuck known as ROOT files.
[+] [-] Ygor|10 years ago|reply
"SQLite does not compete with client/server databases. SQLite competes with fopen()."
[+] [-] dr_zoidberg|10 years ago|reply
[+] [-] protomyth|10 years ago|reply
1) https://en.wikipedia.org/wiki/Soup_(Apple)
[+] [-] batou|10 years ago|reply
[+] [-] shocks|10 years ago|reply
> Miscellaneous micro-optimizations result in 22.3% more work for the same number of CPU cycles relative to the previous release. SQLite now runs twice as fast as version 3.8.0 and three times as fast as version 3.3.9. (Measured using cachegrind on the speedtest1.c workload on Ubuntu 14.04 x64 with gcc 4.8.2 and -Os. Your performance may vary.)
[+] [-] eblume|10 years ago|reply
[+] [-] daheza|10 years ago|reply
[+] [-] gtrubetskoy|10 years ago|reply
[+] [-] coleifer|10 years ago|reply
http://charlesleifer.com/blog/sqlite-small-fast-reliable-cho...
[+] [-] joshbaptiste|10 years ago|reply
[+] [-] applecore|10 years ago|reply
[+] [-] DrJokepu|10 years ago|reply
[+] [-] toyg|10 years ago|reply
[+] [-] developernotes|10 years ago|reply
While not exactly what you are looking for I can understand the sentiment. SQLCipher provides a project to time the performance of queries when run against standard SQLite vs. SQLCipher on iOS.
https://github.com/sqlcipher/SQLCipherSpeed
[+] [-] thomaslutz|10 years ago|reply
[+] [-] PythonicAlpha|10 years ago|reply
One of the best pieces of free software around.
Where else do you find software, that was very good implemented from the beginning and is so carefully enhanced and optimized? (And not only for new "features") -- I remember no official available example.
[+] [-] arandomdude|10 years ago|reply
[+] [-] wxs|10 years ago|reply
Faster predictions mean we can handle more types of errors (more missed characters, more complex typos) in the same time budget. Thanks SQLite, you guys are awesome.
[+] [-] billK|10 years ago|reply
[+] [-] jmnicolas|10 years ago|reply
One thing for sure, they never worked for AMD or Nvidia marketing department ;-)
[+] [-] NelsonMinar|10 years ago|reply
[+] [-] shredwheat|10 years ago|reply
Has most of that been worked out between SQLite and newer Linux kernels, or is that a pit waiting for other applications that go the same route?
[+] [-] coleifer|10 years ago|reply
http://charlesleifer.com/blog/building-the-sqlite-fts5-searc...
[+] [-] fiveoak|10 years ago|reply
[+] [-] coleifer|10 years ago|reply