Entity Framework for DBAs

re: Entity Framework for DBAs

Afshin Gousheh — Mon, 10 Mar 2008 02:58:29 GMT

After using Linq to SQL on a small project I was impressed. At least on small projects it would save a lot of time by just dragging and dropping your tables into the designer and you have a data access layer; impressive. Unfortunately, until then I did not know that Linq is very much a SQL Server product.

I had read in a few places that support for Linq to Entities would be available for other databases. I have researched and actually tried what was developed for Oracle and it is practically useless at this time.

It is now clear that, Oracle is not going to support Microsoft in this endeavor. Oracle considers Linq as a threat (Linq depends on database intelligence rather than tuning for QEP), and Microsoft as a competitor that is having an effect on its sales. Therefore My questions are:

Can Microsoft fund the development of a driver for Oracle that supports Linq to Entities?

Is Microsoft interested to see a well functioning driver for Oracle that supports Linq to Entities?

Slower response time can be accepted in many of our applications; however we can not justify replacing a good RDBMS in order to use Linq.

SoCal MSDN events for Web Developers - slide deck and links

Contagious Curiosity — Wed, 05 Dec 2007 19:11:10 GMT

Presentations given in Irvine and Riverside, CA - here's the deck and links for more information about

re: Entity Framework for DBAs

MSDNArchive — Wed, 28 Nov 2007 21:29:40 GMT

Gregg,

Instead of showing the exact steps, I wanted to give pointers to the different parts of the technology that could be used. A how-to guide would be very long, and would have to go into great detail.

The reason why it would need to be long is that it isn't simple. Very few things are simply when dealing with large databases - they are complex beasts. A slow database query can be solved with an index, but a how-to for indexes would be a long post indeed! But the first step is knowing that an index could help - which is the intention of this post.

Thanks,

Erick

re: Entity Framework for DBAs

Gregg Murray — Wed, 28 Nov 2007 20:38:13 GMT

The article asked some very important questions about the LinkQ query presented :

What exactly is this going to do to your database? How many table scans are going to occur? It might be a great query, or it might bring your server to its knees. What happens when you need to normalize the Customers table for performance? What is it that we gain for this uncertainty?

But the article NEVER ANSWERED THE QUESTION or showed how many steps the DBA would have to go through in order to answer it. We are just given some vague suggestion that afterward we will have more control. My suspicion is that it if it were as easy as you suggest, the "how to" would be inlcluded in the article.

re: Entity Framework for DBAs

MSDNArchive — Sat, 29 Sep 2007 02:52:06 GMT

Jason,

The primary idea of having the conceptual model is that it shouldn't change - and when it does, it should be due to a business need. If the business need doesn't change, then the conceptial (and logical) model should remain the same. It is usually the operations on the Entities that changes quite a bit, which is expected, and not impacted by the EF.

I think that the idea of the EF as a dependency isn't the correct idea, any more than the concept of an Interface is a dependency. It's a way to allow two systems to agree on a common way to communicate with each other. We have this today, it's just not centralized and nor formalized, which makes it too easy to break. And when it does break, you don't know until you get a runtime error.

The issues with performance are valid - it's almost always going to be faster to write applications that lie closer to the database. This is true in all programming - machine language is faster than C, which is faster than C++, which is faster than C#, etc. However, the question you need to ask yourself is how often do you want to write the same data access code?

Thanks,

Erick

re: Entity Framework for DBAs

Jason C. — Sat, 22 Sep 2007 00:09:50 GMT

In most shops given the rapid application development cycles, the logical model changes quite a bit thru the project life cycle and even during support phases. In such an environment - instead of having to change the LINQ/Entity queries within the code any time a change occurs, it is better to leave the db code to a seperate database layer (encapsulated by stored procs/views/functions).

The LINQ/EF model creates an unnecessary dependency and would make application development more complicated and inflexible. Extremely performant and flexible applications can and have been written using the current model using the "Muddy API"s that you mention. Hope MS is not creating a new complication/problem just in the name of coming up with innovative technologies/APIs. We have seen that already with technologies with COM+/MSMQ and buzzwords from Redmond like Windows DNA/WinFS etc.

All you can LINQ » Entity Framework for DBAs

All you can LINQ » Entity Framework for DBAs — Wed, 01 Aug 2007 05:16:41 GMT

PingBack from http://linq.blogstogo.com/2007/07/31/entity-framework-for-dbas/