What are your experiences with SQLite and/or Firebird

sethmo

Active Member
Joined
May 23, 2012
Messages
37
Reaction score
0
Location
Joburg
Hi all

I'm working on a C# WPF MVVM project for and of mine and I and after heroically (read: stupidly) trying to use text files for a basic database for quick prototyping (I know, don't ask, in my head it was like, "It's only 5 records, how bad can it be?"). I'm about a week in, the app works fine, but ja, I need something a little more robust - auto-increment would be a wonderful start...lol...

I've got a lot of experience with MySQL, been using it for years now with Toad for MySQL (it's best, bro), I've dabbled with MSSQL and did Oracle and Interbase for university and I'm well-versed in using XML - so I'm no slouch when it comes to database design. Yet, strangely enough, I can't for the life of me use Access.

Seriously, though, since I'm still prototyping and would like to create binaries for him to install on his machine for user testing, I thought it might be better if I use an embedded database for the program, rather than ask him to install and configure any of the "heavyweight" RDBMSes. I poked around and shortlisted 3, SQLite, Firebird and Microsoft Compact CE but decided to drop CE because it has way too many limitations. I'm as yet mostly undecided, I'm leaning more towards SQLite just because it's more popular and has more documentation/extensions, etc...However, out of curiosity, I just wanted to get some opinions from people who've used either/or. It'd be great to hear from someone who's used both and can give comparisons and reasons for one over the other.

Thanks.

Sethmo
 
Firebird is beyond excellent for anything from embedded to enterprise. And it's rock solid, never giving a days problem. Smaller installations can be restored in minutes if a server goes down. There's also a lot of Interbase/FB documentation and great forum support if you fall short! Good luck.
 
Firebird is beyond excellent for anything from embedded to enterprise. And it's rock solid, never giving a days problem. Smaller installations can be restored in minutes if a server goes down. There's also a lot of Interbase/FB documentation and great forum support if you fall short! Good luck.

Thanks, that's pretty much what most people have to say about it. Where it seems to shine is in client-server environments, SQLite is better suited to single-user/single-machine. Have you used it with Entity Framework? I've been reading about it and itching to try it, seems far more fun than SQLCommands and "SELECT * FROM" in ADO.NET, lol...
 
What about MongoDB?

Haven't really checked it out - I'm not too clued up on NoSQL. I'll give it some thorough research, seems like a viable option. I just have to get my head around the non-relational DB setup. Thanks for the idea.
 
Embedded mongodb seems to be severly lacking. It's also AGPL

If you really need a document store, how about http://ravendb.net

I've just read through this https://msdn.microsoft.com/en-us/magazine/hh547103.aspx and it makes a very compelling case for these types of databases, especially Raven, which is built to be integrated with .NET, a giant plus for me, I primarily work with C#. I see, though (and I stand to be corrected), that these databases connect to a server via a URL, kind of like MySQL, where I use XAMP on my localhost. Am I right in assuming a client, say, my friend who'll be testing, would have to install XAMP or IIS or something similar to use it? That pretty much kills the no-config feature of the embedded DBs.
 
Ended up giving SQLite a go, couldn't get Firebird embedded going. I tried it out with Entity Framework, seems they don't play nice. Then tried SQL Server Compact CE, turns out it doesn't like EF either. So I moved "down a level" and tried SQLite and CE with ADO.Net, which is nice, but a coding nightmare when it comes to handcoding a data access layer.

I poked around a bit, even though Microsoft is looking to replace it with Entity Framework, I'm quite liking LINQ. Which means LINQ to XML becomes a distinct possibility, although for now, I'm giving it a go with SQLite - and I'm liking the results. I think I'll go the LINQ route, since it renders the backing DB redundant.

Thanks for the ideas. I am intrigued about Raven and MongoDB now, though. Right now this project would benefit from a relational database system, but I can see huge potential for them in my trading app!
 
SQLite is really really simple. For prototyping and small / portable / mobile DBs it's perfect. NoSQL is not relational so a different animal altogether - few NoSQL flavours are ideal for stats. Mongo and Couch are examples of document store flavours - quick when storing large gobs of text info but uber clunky for performing calculations on stored data or relating stored data.
 
I've read about it, seems that's the embedded DB of choice! Is it free/open source? That's the appeal of the other two. Also, for some reason, I thought its development was stopped recently.

It's unfortunately not free no. But the dev definitely didn't stop. We received an update just the other day.
 
I settled for SQLite and a micro-ORM called PetaPoco. If you're interested in looking at those, the major players are PetaPoco, Massive, Dapper (StackOverFlow uses this to manage their database CRUD for posts), Simple.Data, ORMLite and FluentData. PetaPoco won out because of its SQLBuilder. At some point, I'd like to try Firebird, but for now, this is a solution I can live with

Linq to Sql ended up being quite a frustrating fail, you know life is rough when you've resigned yourself to handcoding a DAL with ADO.Net!
 
It's unfortunately not free no. But the dev definitely didn't stop. We received an update just the other day.

Ja, I saw. I'm on a tight budget (read: no budget) so shelling out cash at this point's not an option. As far as I know from all the reading, everything else is pretty much fighting for 2nd place after Vista.
 
SQLite is really really simple. For prototyping and small / portable / mobile DBs it's perfect. NoSQL is not relational so a different animal altogether - few NoSQL flavours are ideal for stats. Mongo and Couch are examples of document store flavours - quick when storing large gobs of text info but uber clunky for performing calculations on stored data or relating stored data.

Ja, that's pretty much why I settled on it and (call me "special") couldn't figure out how to get Firebird going. It's not just a case of pushing install on NuGet, I downloaded all the files, copied this and that, renamed the one .dll and I was still getting error messages on VS. This is one .dll (I use Nuget just because it auto-updates the app.config file), and one more click for PetaPoco.

I've no real need for NoSQL, it would be an interesting side-project, just to see how it works. I'm intrigued by them. There's another one I saw that kind of tries to replicate relations by using a B-Tree, don't quite remember the name.
 
Interesting thread. Hadn't heard of RavenDB before. Taking a look now.

I'm really not sure what issues you had with SqlCE though. Have been using it for the last 3 years in a fairly large project. It plays very will with Entity Framework.
 
Ja, that's pretty much why I settled on it and (call me "special") couldn't figure out how to get Firebird going. It's not just a case of pushing install on NuGet, I downloaded all the files, copied this and that, renamed the one .dll and I was still getting error messages on VS. This is one .dll (I use Nuget just because it auto-updates the app.config file), and one more click for PetaPoco.

I've no real need for NoSQL, it would be an interesting side-project, just to see how it works. I'm intrigued by them. There's another one I saw that kind of tries to replicate relations by using a B-Tree, don't quite remember the name.

For me the nosql issue is that I've had no need for a Facebook type database... Massive and full of text.
 
Interesting thread. Hadn't heard of RavenDB before. Taking a look now.

I'm really not sure what issues you had with SqlCE though. Have been using it for the last 3 years in a fairly large project. It plays very will with Entity Framework.

For some reason, the DbContext wasn't persisting data to the actual database - same thing happened with SQLite and EF. It looked like everything was being done in-memory. But with ADO.Net, no such hassle. And it's been deprecated for VS2013, which is what I'm on. I downloaded a little SQL Toolbox for SQLite and CE from Microsoft, it's a bit of a hack, though, but it's a neat little thing, replaces the Server Explorer for SQLite and CE.
 
For me the nosql issue is that I've had no need for a Facebook type database... Massive and full of text.

Ja, and it's unrelated, which, when you have tables: Job 1..* ---> Employee, you need the "Relational" part of RDBMS.
 
Top
Sign up to the MyBroadband newsletter
X