I have to admit that I have not used it. But I have been following it for a while and looks promising. Sterling NoSQL OODB for .NET 4.0 http://sterling.codeplex.com/ I've also just came across UnQLite, an embedded NoSQL (Key/Value store and Document-store) database engine, http://www.unqlite.org/ that looks interesting, but doesn't seem to have managed code wrappers yet. Reminds me of SQLite, but you know, without the SQL and BSD 2-clause instead of Public Domain ;) --------- Original Message --------- Subject: Lightweight database From: "Greg Keogh" <[email protected]> Date: 6/3/13 10:24 pm To: "ozDotNet" <[email protected]>
Folks, an app has just grown with a new feature that needs to store of "users", "jobs" and "reports" and the joins between them, If I was using SQLite it would be 3 tables with joins. However, rather than use SQLite this time I'd like to consider an alternative that's even more lightweight to setup and use. The app does not currently use any database technology and the guys managing the project are actually scared of them. Can anyone recommend an in-process database (not necessarily relational!) that is has a friendly managed API, small footprint, not too complicated and is easy to get going? I know this is a lot to ask, but there may be some NoSQL options around that I'm not aware of. The most important issues for me are: (1) Minimal dependencies (2) Simple managed API. I'm running a few web searches now for such things, and I can see Redis, Mongo, Couch, Raven, db4o, Cassandra, Eloquera, Lucene, and the list goes on and on. There are too many choices and it would take many days of hard slog to work out which one would be suitable. So perhaps someone has already been through this process?! I've been tempted many times over the last 10 years to write a pure managed single-file database with indexes, and nothing much else (no transactions, no client-server, no schemas, etc). However, I decided to leave it to the experts, and it looks like there are too many of them, and they all over-engineer their works. Cheers, Greg K
