Re: Having difficulty refactoring a DB application

From: Topmind (topmind_at_technologist.com)
Date: 10/10/04 

Date: 10 Oct 2004 10:28:18 -0700

Why change it then? Don't let OO zealots mess up a working
data-centric
application. Databases and SQL are NOT evil. Nobody has proven them
evil.

RDBMS and OO will never get along because they have fundimental
differences in philosophy.

1. Declarative Vs. Imperative Interfaces - Relational thinking tends
to use data as interfaces, not behavior as interfaces. It thus has a
declarative tilt in design philosophy in contrast to OO's behavioral
tilt. (However, some relational proponents may perhaps propose going
hog-wild with triggers, etc. to provide complex behavior, but I have
not met any here.)

2. Schema Bound - Objects don't have to follow a "parent schema" as
far as which attributes or accessors an object has while table rows
must follow the entity's schema. However "dynamical relational" theory
may also provide this, although it does not exist in practice yet.
Still, a given row must belong to one and only one entity. The closest
thing in OO is inheritance, but it is generally tree-shaped and
optional.

3. Access Rules - In relational, attributes are accessed and altered
through predefined relational operators, while OO allows each class to
create it's own state alteration interface and practices. The
"self-handling noun" viewpoint of OO gives independence to each object
that relational does not permit. This boils down to a "standards
versus local freedom" debate. OO tends to argue that relational
standards limit expressiveness, while relational proponents suggest
the rule adherence allows more abstract math-like reasoning,
integrity, and design consistency. My view is that OO fails to factor
common "database verbs" to one spot, instead letting each class
reinvent them from scratch and clutter up an interface (getX, searchX,
deleteX etc. where X is every class), and this is a gross violation of
"once and only once" (poor interface factoring) and bad abstraction.

4. Uniqueness Observation - Row identities (keys) generally have a
text-representable form, but objects don't require an
externally-viewable unique identifier.

5. Normalization - Relational normalization practices are often
ignored by OO designs. However, this may just be a bad habit instead
of a native feature of OO.

-T-
oop.ismad.com

----------------original message-----------------
> List:
>
> Apologies if this is a repeat.
>
> My current project is a mess of close-coupling. I have sensible classes
> that work for my "business model objects"
>
> I have a sensible database definition that more or less works for the
> application. We're still refining certain aspects of it, but it's more
> or less set.
>
> The problem as I see it is that I've SQL statements scattered
> willy-nilly throughout the application.
>
> Seems to me an object should be responsible for its own creation,
> destruction and assignment.
>
> I've come up with two possible solutions to this.
>
> The first is to make the business objects aware of the associated stored
> methods. The problem with this is that should the underlying methods
> change, the classes will have to change to account for that.
>
> The second is to put in an adapter class that knows how to access the
> database.
>
> Much of the difficulty for me is reconciling SQL's idea of a "record
> set" with well-formed well-behaved objects. Some querys returns more
> than one record, and others return records in different form, ill-formed
> or partial objects. Some of this could be massaged, but I'm not certain
> about proven methods for doing this.
>
> Any other ideas about how to structure this aside from the two I've
> stated?
>
> Any relavant patterns, either in GoF or other references that apply to
> this situation?
>
> Thanx
>
>
> Charles

Relevant Pages

  • Re: dbdebunk Quote of Week comment
    ... > a lot of really bad SQL programmers. ... But SQL does not have a pointer data type or the ... > being told to design a database. ... But why is little Cindy Lou Who employee ...
    (comp.databases.theory)
  • Re: DBMS and lisp, etc.
    ... Naively implemented with SQL, again for 10 ... (1 query for the initial orders, 1 query for each order for its ... soon as you upgrade to the SQL database. ... (eq (order-customer orderA) ...
    (comp.lang.lisp)
  • Re: dbdebunk Quote of Week comment
    ... > a lot of really bad SQL programmers. ... a surrogate key should support the primary key. ... But SQL does not have a pointer data type or the ... > being told to design a database. ...
    (comp.databases.theory)
  • Re: dbdebunk Quote of Week comment
    ... But SQL does not have a pointer data type or the ... More and more programmers who have absolutely no database training are ... But why is little Cindy Lou Who employee ...
    (comp.databases.theory)
  • Re: Just say no to threads [Was: Software architecture]
    ... they knew there was going to be a database in the app. ... Now my colleague just spent a couple/three weeks designing an SQL ... Turns out they have a flat file of sample information, ...
    (comp.object)