Is DB_LINQ + Non-SQL Server Database an acceptable substitute for LINQ to SQL with SQL Server?

Question

I'm trying to decide what database system to use for my next project which will be using VS.NET 2008 and will likely have a bit of LINQ code in it. No LINQ support may be a dealbreaker for any database system. Is DB_LINQ mature enough to allow other DBMS' to stand on even footing with SQL Server? Or should I just not even look into other systems if LINQ is a dealbreaker?

Answer 1

LINQ != LINQ to SQL. LINQ to Entities works just fine with many non-SQL-Server DBs.

Answer 2

Well, I haven't used it myself - but I've helped somebody using it (various bits of Expression code - I believe some made it into the DbLinq codebase), and they were generally happy with it.

Ultimately, I suggest you need to find which are the critical features you need, and run tests (unit, integration or ad-hoc) to see if it can meet your specific requirements.

Answer 3

Ultimately, if you are at a Microsoft shop there shouldn't be any problem using Linq to SQL for your OR/M needs.

If I needed a true OR/M solution I would experiment with Linq to Entities and use NHibernate if I needed something immediately stable. It's been around the block a few times and is pretty stable. To my knowledge Oracle has still not shipped a true Linq to Entities implementation and until they do you'll need to get by on the various community efforts like DbLinq. Catharsis is a pretty good reference implementation.

Answer 4

I'd avoid using DBLinq for production code... many of Linq-To-SQL's features aren't implemented, and walking through the source code shows a low level of maturity... many of the methods are not implemented or marked as "unterminated".

...you've been warned!