Salakhetdinov Shamil
mcp2004 at mail.ru
Sun Apr 26 13:11:49 CDT 2009
Hi Athur, I used PITA in its first most common meaning. I would love to contact with Paul Nielson. I have also written my own ORM thing/light framework for MS SQL, and it was/is used in real life business apps, which are bringing quite some money/savings to the customers every day but I'd be happy to switch to EF thing from MS provided there will be some guarantee MS will not stop EF development as they did with LINQ2SQL.... As for keeping Orders+OrderDetails in the most complicated scenarious as well as the case when "users could define the attributes of various objects they dealt with" that could be done I believe by using Software Design Patterns for Business Layer (C#/VB.NET custom coding) and keeping detail types/attributes on database level in XML fields but (fully) indexed special way for searching/data retrieval - just one approach to handle this issue in 21st century... Data retrieval of objects' data from relational database with variable parts kept in XML (or JSON(?) - never used it here yet) is usually quick enough from practical point of view, and parsing such XML/JSON data into "relational" structures/tuples is also quick enough in code - and then such parsed XML can be delivered to forms/reports special way (as ObjectDataSource in .NET) for every special form/reports - that's what programming is still needed in this world... I could be missing something - please explain/describe your point of view/experience in more details... Thank you. -- Shamil -----Original Message----- From: Arthur Fuller <fuller.artful at gmail.com> To: Salakhetdinov Shamil <mcp2004 at mail.ru>, "Discussion concerning Visual Basic and related programming issues." <dba-vb at databaseadvisors.com> Date: Sun, 26 Apr 2009 12:30:58 -0400 Subject: Re: [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 > > > > > >