Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> comp.databases.theory -> Re: What databases have taught me

Re: What databases have taught me

From: Frans Bouma <>
Date: 23 Jun 2006 09:54:02 GMT
Message-Id: <>

JOG wrote:

> Well after a brief hiatus I have just ploughed through the whole 800
> posts of the OO vs RM thread. Some discouraging stuff indeed. Over the
> last few years a study of database technology, helped greatly by
> discussions in cdt, has educated my opinions significantly, and
> perhaps my albeit slow progress can be illuminative to others.

        Please also realize that in comp.databases*, a lot of people are die-hard database pundits who preach to implement everything of an application inside the DB, including BL.

> - I started life as a procedural programmer.
> - I adopted OO and soon got the 'aha' click described by R. Martin.
> - I spent years coding large OO projects, with beautiful, elegant
> architectures.
> - I spent further years practically gnawing my arm off attempting to
> adapt my perfect OO designs as requirements inevitably shifted and
> exceptions arose.
> - I finally realised that my 'aha' was utterly illusionary, and that
> my code, being OO, was inevitably and irrecovably imprisoned in a
> hierarchical strait-jacket

        I don't know anything about you nor your projects, so I can't comment on the experiences you got if they're the result of OO or the result of applying OO wrong.

        What I can say is that if you don't realize that <insert tech / paradigm here> is just a tool to get to the goal you want to achieve: an executable solution to the problem you want to solve, that same tech/paradigm will sooner or later bite you because it will have limitations and shortcomings.

> OO is hierarchy. Enforcing a hierarchy where none exists is an utterly
> dire and destructive artifice. If one does not recognize this, one is
> etiher wholly uneducated (given that the battle between
> hierarchy/networks and a relationship based models occurred decades
> ago) or has not been involved in enough large scale OO projects. Yet
> still this turgid "chinese doll" approach prevails through Java, C++
> and the bastard child of them all, XML.

        True, a good example is a Math library in an OO language runtime library. It often is implemented as a library with static methods in one big class or several different classes without state nor specific type, just a vehicle to hold the static methods together.

        That doesn't mean OO sucks, it means for functional problems which can be appearing in any domain, it might be best to use a functional / procedural approach instead of an OO.

        The same applies to using OO-esk constructs in an procedural language. I think a lot here have seen or have written C-structs with function pointers to use some kind of OO-esk approach in their procedural programs because it would fit the problem better. That's not implying procedural languages suck, it illustrates there might be better solutions to that particular problem in that particular domain.

> I still code via OO as I currently have no other preferable tools. And
> yes, I still absolutely take pride in my crafted generic OO designs.
> However I now don't waste precious time trying to perfect them,
> because I know they are by definition inflexible, brittle and flawed.
> So I make them lightweight and replacable, aware of the limitations
> of the neanderthal paradigm that we are currently lumped with.

        I think that's, just judged by the sentence above, a flawed vision on reality, but that could be caused by experiences I or others didn't experience, so I won't judge you on that.

        What I can say is that often people are too blinded by the paradigm they use. Take for example Object oriented data-access. Entities as objects in your program, working with object graphs, etc. it all matches the paradigm used and lets you make progress.

        Though what to do when you have to create a simple list of data on the screen with all the OrderEntity's fields (attributes so you will) and also the companyname of the related customer. ? that can be a struggle, as you effectively have to create a new class, project the order data onto a list of instances of that class and together withthat have to add the related CustomerEntity's companyname into it as well. It will likely require you to write extra code if you solely have to work with the entity classes at hand.

        Does it then suck in the core of its being? no, it just doesnt fit that specific problem. A solution could be to use an untyped container, the meta-data of orderentity and customer entity and with OO blocks build a new list of dataelements and use the mechanism at hand to get that data.

        Small example of how OO could get into your way if you're focussed on a limited part of the whole spectrum: with the same OO constructs you can for example use factories and meta-objects to build what you need easily without having to fall back on procedural approaches.

> So apologies for the rant, but I find the current status quo very
> frustrating. I can only hope that this situation will change as the
> field matures and hierarchy-where it does not belong finally dies a
> long overdue death.

        "Use the right tool for the job, Luke"


Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website:
My .NET blog:
Microsoft MVP (C#) 
Received on Fri Jun 23 2006 - 04:54:02 CDT

Original text of this message