Re: Mixing OO and DB

On Feb 9, 8:17 pm, Patrick May <p..._at_spe.com> wrote:
> mAsterdam <mAster..._at_vrijdag.org> writes:
> > Patrick May wrote:
> >> I prefer to work with people who understand procedural,
> >> relational, OO, and functional programming. The boundaries between
> >> these paradigms are not sharp -- useful techniques span paradigms.
> >> Ultimately I'm looking for a gestalt development environment that
> >> leverages the benefits of the superset of these techniques to
> >> deliver high quality software. That's the real goal, after all.
>
> > That is stricly one side of the fence - it is the goal for a
> > software development process. The goal for a DB is to serve as a
> > vehicle to manage data.
>
> I disagree. Software is a means to an end, not an end in itself,
> at least in the vast majority of commercial settings. Databases are
> just one type of software. The end goal is to provide business
> value. Quality software, meaning software that meets the current
> needs of the business, that can be easily extended to meet future
> needs, and that is economically feasible to develop, provides that
> business value. No business really wants a database per se, but many
> do want the benefits of rapid access to consistent business
> information.
>
> > Paradigm, gestalt development environment, leverages the benefits of
> > the superset of these techniques, gestalt development, I'll requote:
>
> >>> Let's cross this divide, and behave as if it is a real border.
> >>> This means you can't carry all of your preconceptions, and you
> >>> will have to adapt your language.
>
> > Do I need to explain?
>
> Evidently, because I don't accept that the divide exists in any
> meaningful sense. I use multiple paradigms as the situation warrants
> and I work with a number of people who do as well. They're all just
> different tools, each with advantages and disadvantages. Grouping one
> set of tools together and calling it "relational", another set "object
> oriented", and another set "functional" is useful to identify those
> that complement each other, but it's important to realize that those
> sets are not disjoint. It's also important to realize that the tools
> in each set complement each other _in a particular context_. In a
> different context, that is, a different problem or solution domain,
> different sets of tools may make sense.

But OOP and relational often don't compliment each other, but instead fight over territory. Unless clear and logical rules form that tell us when to stop one and start the other, this problem is not small.

Product/domain classification systems are a prime example. If you manage them in the database, then you don't need polymorphism (unless you duplicate information unnecessarily). Further, the set-oriented classification systems used in relational are often not compatible with the DAG/tree-based classification systems preferred by OO.

It's not just where the classification is represented, but how. Personally, I think sets are superior to DAG-based taxonomies for managing variations-on-a-theme.

>
> There are more things in heaven and earth, mAsterdam, than are
> dreamt of in your paradigms.
>
> Regards,
>
> Patrick
>
> ------------------------------------------------------------------------
> S P Engineering, Inc. | Large scale, mission-critical, distributed OO
> | systems design and implementation.
> p..._at_spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)

-T- Received on Sun Feb 10 2008 - 06:58:27 CET