[dba-VB] ADO.NET Entity Framework - to use or not?

As far as I know, there are two distinct meaninings of the acronym PITA. One
is Pain in the Ass and the other is Point In Time Archicture. I was involved
in one significant project which used the latter meaning, and several dozen
which used the former.

On the subject of ORM, I suggest that you contact Paul Nielson, who is a SQL
MVP and author of the SQL Bible books, and who has written an ORM thing for
SQL Server. My basic take on this is at the low end there will be four
procedures for each table (Select, Update, Delete, and Insert). These are
quite easy to generate. The trick is in how to handle objects -- consider
the classic Orders+OrderDetails example, just to keep the discussion simple.
In the relational world you treat Orders and OrderDetails as separate things
-- first you add the Order, then you add one or more Details to said Order.
This can grow rapidly more complicated given the existence of DetailTypes
(Been there, done that). I'll let you run free with the concept of Detail
Types, but suffice to say that they have a few columns in common and many
unique to the particular type. (For example, Car Rental vs. Hotel Room
Booking vs. Seat in a U2 concert.)

Suppose that you want to handle this aggregation as an object. What do you
gain by doing so?

In another app I once worked on, users could define the attributes of
various objects they dealt with. They could add a potentially unlimited
number of attributes to these objects, which in this case were pulp and
paper rolls. Various clients were interested in these or those attributes,
and we modeled this as rows in a table. IOW, one virtual row actually
expanded to N rows in a child table, and these were all grabbed and
assembled into one row, kind of like a crosstab thing.

It sucked. I spent a lot of time enhancing the performance and chopped it by
ten, but it still sucked. It took upwards of 10 seconds to retrieve a given
object. The speedy solution was to include all columns in the OrderDetails
table and then restrict the view to the particular columns of interest to
the particular client. This worked well in terms of performance but meant
that our developers had to recreate various views for each client.

A.

On Sun, Apr 26, 2009 at 5:28 AM, Salakhetdinov Shamil <mcp2004 at mail.ru>wrote:

> Hi Gustav,
>
> Clarification to the subject title -- I meant -- "to use or not to use now
> for real life applications development" -- for sure -- use in our ongoing
> Northwind.NET project, in one of the future releases.
>
> Thank you.
>
> --
> Shamil
>
> -----Original Message-----
> From: "Gustav Brock" <Gustav at cactus.dk>
> To: <dba-vb at databaseadvisors.com>
> Date: Sat, 25 Apr 2009 23:07:38 +0200
> Subject: Re: [dba-VB] ADO.NET Entity Framework - to use or not?
>
> > Hi Shamil
> >
> > There probably isn't a definitive recommendation - as always, it depends
> - but I must say I find it quite fascinating to "leave" the tables and views
> and work with objects instead.
>
> <snip>
> _______________________________________________
> dba-VB mailing list
> dba-VB at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-vb
> http://www.databaseadvisors.com
>
>