[dba-VB] SPAM-MED: dba-VB Digest, Vol 66, Issue 45

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
>**************************************





More information about the dba-VB mailing list