Robert L. Stewart
robert at webedb.com
Mon Apr 27 12:22:22 CDT 2009
At 12:00 PM 4/27/2009, you wrote: >Send dba-VB mailing list submissions to > dba-vb at databaseadvisors.com > >To subscribe or unsubscribe via the World Wide Web, visit > http://databaseadvisors.com/mailman/listinfo/dba-vb >or, via email, send a message with subject or body 'help' to > dba-vb-request at databaseadvisors.com > >You can reach the person managing the list at > dba-vb-owner at databaseadvisors.com > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of dba-VB digest..." > > >Today's Topics: > > 1. Re: ADO.NET Entity Framework - to use or not? (Michael Maddison) > 2. Re: SCRUM: Northwind.NET v.1.1 (Alpha) with MS Access Backend > published (Gustav Brock) > 3. Re: ADO.NET Entity Framework - to use or not? > (Salakhetdinov Shamil) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Mon, 27 Apr 2009 17:27:32 +1000 >From: "Michael Maddison" <michael at ddisolutions.com.au> >Subject: Re: [dba-VB] ADO.NET Entity Framework - to use or not? >To: "Discussion concerning Visual Basic and related programming > issues." <dba-vb at databaseadvisors.com> >Message-ID: <59A61174B1F5B54B97FD4ADDE71E7D014F6957 at ddi-01.DDI.local> >Content-Type: text/plain; charset="us-ascii" > >Don't mean to intrude, but are you looking for something like >http://www.nettiers.com ? >We've used it in several projects, but not the one we are working on >now. >It works pretty damn well IMO. > >Cheers > >Michael M > > >-----Original Message----- >From: dba-vb-bounces at databaseadvisors.com >[mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller >Sent: Monday, 27 April 2009 2:31 AM >To: Salakhetdinov Shamil; Discussion concerning Visual Basic and related >programming issues. >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 > > > > >_______________________________________________ >dba-VB mailing list >dba-VB at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/dba-vb >http://www.databaseadvisors.com > > > > >------------------------------ > >Message: 2 >Date: Mon, 27 Apr 2009 09:57:46 +0200 >From: "Gustav Brock" <Gustav at cactus.dk> >Subject: Re: [dba-VB] SCRUM: Northwind.NET v.1.1 (Alpha) with MS > Access Backend published >To: <dba-vb at databaseadvisors.com> >Message-ID: <s9f581ae.029 at cactus.dk> >Content-Type: text/plain; charset=US-ASCII > >Hi Mark and Stuart > >Many options are available for a database (server) to be used with Dot Net. > >However, SQL Server CE has the advantage - within its limitations >like lack of stored procedures etc. - that it uses the same SQL >syntax as its big brothers. >Also, a main idea is to provide a local database for Windows >applications which is very fast and can act as a high-level "cache" >which you in the background synchronise with a central (remote) >server based database engine like SQL Server Express or Standard. >Tools for setting up such a synched remote/local database are >provided which makes this task a snap. > >/gustav > > > >>> stuart at lexacorp.com.pg 27-04-2009 01:03 >>> >Another option is SQLite. I'd go with that rather than CE. > >Not for multi-user applications, but if you ned a small, lightweight >in-process SQL data >engine for a single user application it's well worth looking >at. Just a single small DLL to >distribute with your application ( < 450KB). > >There are .Net wrappers available which make it very simple to use. > > >On 26 Apr 2009 at 23:02, Mark Breen wrote: > > > Hi All, > > I have been seeing SQL Server compact edition for a while now, but I have > > not read up about it yet. If it is so light as Gustav just outlined then I > > really should study it. It sounds just what the doctor ordered, I have > > always thought, since MSDE 1.0 was launched, that it was too heavy. > > > > However, I re-call struggling with a machine that did not have > Jet 3.51, and > > I suppose that installing / using SQL Server CE may also have issues. > > > > What the pros / cons to building an XML only BE? > > > > As I write this, I see the following potential list of BE's > > > > XML only - Simplest Implementation at installation time. > > SQL Server CE - Not Sure as have to study > > Jet - Ideal for low volume of data and low numbers of users. > > SQL Server Express - where mid sized data, mid users and hand installation > > is possible if required. > > SQL Server Standard -where mid sized data, mid users and hand installation > > is possible if required and cost is not an issue > > mySQL - high data size and licencing cost is an issue > > Oracle - Just because it is there. > > > > So where does that leave the discussion on what to do next? > > > > I am off to read up on SQL Sever CE > > > > Mark > > > > > > > > > > > > 2009/4/26 Gustav Brock <Gustav at cactus.dk> > > > > > Hi all > > > > > > It is my impression that - in the mind of MS - a downgrade from > SQL Server > > > 200x (server-based) should be the SQL Server Compact Edition which is > > > file-based as Access/JET is except that it is local and not > shareable but is > > > deployable via Click-Once. > > > Next level below is pure XML. > > > > > > Using Access/JET - or MySQL or any other db - is simply another > "business". > > > > > > /gustav > > > t > > > > > > >>> max.wanadoo at gmail.com 26-04-2009 19:26 >>> > > > Arthur: > > > Because... > > > 1. I don't know how to do this. > > > 2. I don't see any benefits other than more pain. > > > 3. I don't see any DAO.Properties on the SQL tables. > > > > > > Inertia. Perhaps. > > > > > > Max > > > > > > > > > -----Original Message----- > > > From: dba-vb-bounces at databaseadvisors.com > > > [mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller > > > Sent: 26 April 2009 15:39 > > > To: Salakhetdinov Shamil; Discussion concerning Visual Basic and related > > > programming issues. > > > Subject: Re: [dba-VB] SCRUM: Northwind.NET v.1.1 (Alpha) with MS Access > > > Backend published > > > > > > Shamil, > > > > > > It is not interesting to me, personally. All my database > activity occurs in > > > SQL Server and MySQL. The concept of an Access BE is for me so > 20th century > > > LOL. However, I realize that not everyone agrees and that some > folks might > > > like an Access BE. (Although given that SQL Express is free, I frankly > > > don't > > > understand this, other than the force of inertia.) > > > > > > Arthur > > > > >------------------------------ > >Message: 3 >Date: Mon, 27 Apr 2009 13:50:15 +0400 >From: Salakhetdinov Shamil <mcp2004 at mail.ru> >Subject: Re: [dba-VB] ADO.NET Entity Framework - to use or not? >To: "Discussion concerning Visual Basic and related programming > issues." <dba-vb at databaseadvisors.com> >Message-ID: <E1LyNTb-0006Kd-00.mcp2004-mail-ru at f229.mail.ru> >Content-Type: text/plain; charset=koi8-r > >Hi Michael, > >Thank you for your feedback. > >In my opinion we're looking for the ways to avoid using custom tools >as .netTiers, CSLA.NET, own custom frameworks (I have got developed >one like .netTiers, maybe with not that much features but rather >similar AFAIS - my own also works pretty well in real life apps) - >the main current "killer" framework to try is MS ADO.NET Entity >Framework, which is supported by .NET Framework SP1 (VS2008 SP1), >but which have some limitations e.g. absense of flexible SPs mapping >features (which BTW is not looking as an issue at all to Gustav :) >maybe for me only in our SCRUM team) but all(?) that limitations are >planned to be fixed in VS2010... > >Thank you. > >-- >Shamil > >-----Original Message----- >From: "Michael Maddison" <michael at ddisolutions.com.au> >To: "Discussion concerning Visual Basic and related programming >issues."<dba-vb at databaseadvisors.com> >Date: Mon, 27 Apr 2009 17:27:32 +1000 >Subject: Re: [dba-VB] ADO.NET Entity Framework - to use or not? > > > Don't mean to intrude, but are you looking for something like > > http://www.nettiers.com ? > > We've used it in several projects, but not the one we are working on > > now. > > It works pretty damn well IMO. > > > > Cheers > > > > Michael M > > > > > > -----Original Message----- > > From: dba-vb-bounces at databaseadvisors.com > > [mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller > > Sent: Monday, 27 April 2009 2:31 AM > > To: Salakhetdinov Shamil; Discussion concerning Visual Basic and related > > programming issues. > > 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 > > > > > > > > _______________________________________________ > > dba-VB mailing list > > dba-VB at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/dba-vb > > http://www.databaseadvisors.com > > > > > > _______________________________________________ > > dba-VB mailing list > > dba-VB at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/dba-vb > > http://www.databaseadvisors.com > > > > > >------------------------------ > >_______________________________________________ >dba-VB mailing list >dba-VB at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/dba-vb > > >End of dba-VB Digest, Vol 66, Issue 45 >**************************************