Great to see another NoSQL DB on .NET landscape. In my UWP days I had to port LevelDB (https://github.com/maxpert/LevelDBWinRT shameless plug, it's available as nuget package too). But it only works on UWP this seems more robust and it can work on Xamarin.
Is it possible to pre-allocate a fixed-size file with sqlite to then use as a local cache evicting old data? Supporting this may offer a chance to differentiate a bit.
Closest I could find was a workaround that is probably close enough (disable auto_vacuum and delete a giant blob) https://stackoverflow.com/a/4821318.
Battle-tested multiplatform support (and thus reliability) is definitely a key selling point. This is further reinforced by its impressively extensive test suite.
Long ago I lost my first Android smartphone's SMS database since they used to delete + re-create even barely corrupted databases, but by now most of the kinks have been worked out.
Plus it's amazingly fast and is packed with SQL features. For such a small lib, it's a miracle. And the way the author talks about it (he is not from a DB background) it so funny.
A very valid use case is for use in MVPs and side-projects that would be hosted on Azure. I built an MVP using .Net and SQL Server for the database (db was needed only once a day for 30 mins to do batch jobs and save data), only to find out upon deployment that you have to pay about $50/ month minimum to have your 1 SQL Server database up and running, and also that you can't 'switch it off' ever and save $ [1].
So I ended up rewriting parts of the data layer to use SQL Lite and an embedded .DB data file.
This is very interesting to me. I am writing a multi-tenant app with a single RDBMS schema right now and balancing all of my needs (scaling/sharding, partitioning tables, normalizing vs denormalizing) has been challenging.
I've never written a system with a whole database per account. Does anyone have any good reading or examples on this general tactic?
It has it's plusses and minuses. The plusses are that everything is isolated and the data doesn't get too big. It becomes problematic when you need to access multiple clients at the same time (and you probably will at some point). Deployment is harder since you have to do it more. Keeping schema versioning straight is also a pain. Data isolation is inherent in single tenant though.
This is pretty cool. If it has low enough overhead, I wonder if this could be used to replace the current format of ODT (Open Document) files, which right now are basically just zipped up XML documents and image assets
Looking at the file format limitations [1], it doesn't seem like a good fit for an alternative to ODT files. (A cursory judgment based solely on this wiki page has me wondering if they are using the best data structure for an Index, but again, very cursory.)
A question is why you would want to replace the current ODT format? "Just" a zipped up file tree of XML documents and image assets is a pretty robust format choice. There are unzip programs on almost every platform. XML isn't always everyone's favorite markup language, but it's well supported by almost every language ecosystem, and still roughly okay to humanly eyeball if needed. The relative inefficiencies of the textual encoding and verbosity of XML are directly suited for compression efficiency of a Zip file. For most trade-offs of a document file, it's a somewhat resilient option, with likely a long shelf life (both zip and XML technologies have lasted enough decades, and are reasonably well standardized enough, that you can imagine they will continue to be unzippable/readable decades from now).
I’ve tested some hacks to get a file below email server file size limitations. Unzipping an excel file, then tarballing it into a .tar.xz archive can cut the size by 30%, say. The only issue is that the receiver might not know what on earth to do with it!
Another trick is you can repack modern MS Office files with advzip from advancecomp. With -z4 It will use Zopfli to pack them. Further gains can be had with more rounds, (such as -i50). The resulting files can be quite a bit smaller and Office will open them without complaint.
Yet another trick is you can save as binary format files. In Excel this is XLSB. Supposedly those are less compatible across Office versions however.
Because incremental updates are very difficult in a zip file.
The point of an embedded database like LiteDB or SQLite is to allow incremental updates to a file without needing to write out the entire file every time.
The nice thing about tools like SQLite and LiteDB is that they have APIs that are fundamentally similar to APIs that we already know. It keeps the learning curve light so we can spend more time on the task at hand instead of learning a new thing.
Give the size of most ODT files and the power of current computers, incremental updates are completely irrelevant. Regenerating the entire file takes a blink.
But the current format benefit from the XML ecosystem (validation, transformation, namespacing, nesting, semantic markup) that is very handy for a document.
Plus, being text based is a very good selling point if you want your format to last: event in 30 years if you don't have the spec, you can peak in the zip and see what's up.
I needed a small for my C# MAME frontend IV/Play, it didn't matter if it was relational on not. I picked this over SQLite because it's a single native DLL with no dependencies. It also supports POCO mappings (think serialization) which usually requires some ORM type package.
SQLite in .NET is still a little messy - there are several versions in various state of support, and they all depend on multiple packages.
I am developing a mobile game and the BaaS we use (Gamesparks) uses MongoDB. Currently I use SQLite to cache the data locally, but that can be a pain to transform document formatted data to relational, and back. I wish I had known about this before (and I use Unity so the app code is C#).
Interesting, I did not know that. However, I use a 3rd party framework to transform the table rows to classes, and I assume I would lose all that magic conversion. In other words, the reason I go through all the effort of transforming to relational is for querying and updating, but if I just put the raw document in there, I won't have granularity on my querying (I imagine).
Ok this is pretty cool. This is also why I love HN. I've been using SQLite for ~3 years, have I missed this from the beginning or has it been added since then?
Back in the dark ages as everyone upgraded from 32-bit to 64-bit environments, shipping two versions of native dependencies caused extra hassle. However, this may not be much of an issue these days.
"NoSQL" is a meaningless term. Even when strictly taken as either not supporting SQL or not relational, it is a rather useless way to search for options.
