Re: OOP - a question about database access

From: John Urberg (john_urberg_at_no-spam-yahoo.com)
Date: 11/10/03 

Date: Mon, 10 Nov 2003 11:57:38 -0600

"Costin Cozianu" wrote:

> What's wrong with improving the design table by table, and use case by
> use case, one at a time ?

Consider your classic VB+SQL application. SQL is embedded in every form
and report. Every change to a table has ripple effects across the
application. It's an enormous, error prone job. Why not just rewrite the
application and isolate the code from the data access so I can not just
change the data model, but also have the option to change database systems
too?

> It is just because, as I explained in another post here, the data access
> pattern generated from O/R mapping are sub-optimal. Wehn compared to say
> the simplest VB+SQL programmer that has to take the use case from point
> A to point B, the queries issued from an O/R solutions are generally
> less efficient. And they will allways be less efficient than I can
> write, but that's not relevant :)

I realise that. But coding in Java provides sub-optimal performance
compared to using Assembler and I don't think you'd recommend we choose
Assembler, would you?

For the price of creating the objects and mappings and a little OQL here
and there, I no longer have to write any SQL. If you look at a classic
VB+SQL application, that turns out to be quite a significant savings. If
there turn out to be places in the app that perform poorly, I can still go
back and optimize those using hand coded SQL.

> Anyways, model driven, MVC and all that jazz are not the same as they
> were when it was invented in Smalltalk. In typical enterprise apps
> architecture, an object model is just a partial fragment of the whole
> model, that is not necessarily unique -- each request processing will
> have its own copy of some fragment of the model, and has a short life
> span just for the duration of a transaction. So a lot of the original
> philosophy behind it doesn't apply.

I completely disagree. The Smalltalk folks had to deal with the same
thing. I doubt they could load the whole database into memory for every
transaction; they also had to select a specific subset of the object model
just like I do today.

Regards,
John Urberg

Relevant Pages

  • Re: OOP - a question about database access
    ... Object Pascal) +SQL which is a most improved version of VB. ... never a problem in my Delphi apps. ... pretty much the same as you have it in an object model driven app. ... But coding in Java provides sub-optimal performance ...
    (comp.object)
  • Re: OO vs. RDB challenge
    ... > Costin Cozianu wrote: ... > beyond the sphere of DBs and SQL. ... > However since you went on to generalize about the Object Model ... > then yes it would smack of brochure speak. ...
    (comp.object)
  • Re: SQL-DMO equiavlent of sp_addmessage
    ... SQL-DMO is just an Automation Object Model. ... functionality already built into the database engine. ... when an application vendor wants to use MSDE, or the new SQL Server Express ... Is there any point/benefit to using it within a stored procedure, ...
    (microsoft.public.sqlserver.server)
  • Re: OO vs. RDB challenge
    ... Costin Cozianu wrote: ... >> squarely within the reach of SQL and so it makes SQL shine. ... However since you went on to generalize about the Object Model ... Yet when I speak of scenarios that the OM is good at you say they are ...
    (comp.object)
  • Re: Asynchronous Stored Procedure Never Returns - Help?
    ... If you have the Sql Server 2000 or 2005 docs they are thorough and can be ... for Transaction SQL Reference from the drop-down or select a keyword from ... your query in Query Analyzer or Sql Server Management Studio, ...
    (microsoft.public.dotnet.languages.csharp)