Author: mariuz

[See remaining text…] 

Jiri: Firebird is a fully featured RDBMS, with small footprint and zero maintenance. It supports all standard features you’d expect – stored procedures, triggers, views, UDFs, monitoring, online (remote) backup/restore etc. There’s also so called Embedded version, that just one main DLL and few supporting it, without install or need to copy something somewhere. You’ll just reference this DLL and you have all the features of standalone (network) Firebird in your application. And of course, whole Firebird is completely free (and open source).

InfoQ: In the SQL Server world we have to deal with a serious trade-off. If you choose to use the embedded version, SQL Server Compact, then you lose the ability to use a lot of features. Is there any sort of tradeoff like that for Firebird or do you really get access to the whole feature set either way?

Jiri: Absolutely not. Firebird Embedded is fully featured as “big” server. It’s even built from same sources, only with different output (DLL file). You can use everything Firebird offers. And not only that. Migration is super easy. You’ll just take the database file and put it to some place where server can access it and you’re done.

InfoQ: So what’s involved in writing a ADO.NET provider?

Jiri: It’s actually pretty simple. You’re fixing bug, moving with features as Firebird server moves further and improving stability and code itself. Cleanup, refactoring. With all that you’re trying to keep backward compatibility and not introduce some breaking changes. And on the other hand you’re moving along with .NET and ADO.NET (i.e. Entity Framework) world and other data access providers and components.

InfoQ: DId you also work on the Entity Framework provider? If so, what’s your opinion of the ORM?

Jiri: Yes I did. I worker on provider since early versions around 2007. I believe Firebird was first 3rd party ADO.NET provider to have working Entity Framework support (and it’s open source). I think Entity Framework is good ORM, comparable to others, like LLBLGen Pro or NHibernate. It’s not here that long but still very good. I don’t think anybody can say i.e. NHibernate is best because … Every project needs something more and something less. And every ORM (including Entity Framework) has strong points and places where there’s room for improvement.

InfoQ: What areas in particular do you think the .NET-based ORMs need to improve upon?

Jiri: There’s mismatch between relational world and OOP world, even if you believe ORMs are hiding it, it’s there. For simple small applications, this is not a problem. But for a big applications, the ORM needs to be flexible enough to allow really experienced developer hook in and in rare cases when performance is critical or special needs are placed in front of him/her allow to do it own way without creating huge disruption in your code.

InfoQ: If you had more resources available to you (i..e. developers, hardware, etc), what would you like to do with Firebird and .NET that you can’t do right now?

Jiri: Provide more seamless experience for .NET developers using Firebird and improve codebase. Move further faster and provide more features, both from Firebird world and (ADO).NET world.

« Hide it