Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Sat, 03 Jun 2006 00:21:05 GMT
Message-ID: <RB4gg.16728$A26.385961_at_ursa-nb00s0.nbnet.nb.ca>


Andrew McDonagh wrote:

> phlip wrote:
>

>> Andrew McDonagh wrote:
>>
>>> Well for PL/SQL there is ut/PLSQL (http://utplsql.sourceforge.net/)
>>
>> DBs are easy to unit test because they have clean, responsive, and
>> abstracted interfaces.
>>
>> DBs are hard to refactor, and grow their designs in response to 
>> real-world
>> issues. I suspect that's the purpose of the book /Refactoring Databases/
>> by Ambler Sadalage is about.

>
> Agreed.
>
> As for refactoring, most of the difficulty comes down to the limitations
> of the store procedure language

Agreeing to nonsense does not reflect well upon you. Contributing additional gibberish reflects even worse.

A DB is nothing more than a set of facts. As such, a DB has nothing to do with stored procedures.

A dbms might provide a facility for stored procedures, and many vendors do include just such a facility to evade correcting fundamental flaws in their products by forcing that work out onto users where it will be repeated (poorly) thousands or millions of times.

Drawing conclusions about anything other than the stored procedure facility available from a specific vendor based on that facility would be pointless, wrong and rather dumb.

   and development environments not
> supporting automated refactorings.

Refactoring is another gibberish term. Basically all it says is using the low-level abstractions available in OO forces one to do a lot of work for no particularly good reason that one will have to undo and redo later. Giving it a fancy name dresses it up, but doesn't really make it all that desirable to people who have a clue.

> Its possible, just difficult and manual.
>
> One point no one has yet addressed is the use of Java within rdbms - it
> would be interesting to see what issues we have with that.

It's stupid to cripple a higher-level abstraction with a lower-level computational model. What more is there to say about that?

> From personal exposure, it allows for far greater control, development,
> unit testing, refactoring than the store procedure language like PL/SQL.

Yes, well, that's rather like saying that digging a canal with a shovel is easier than digging one with a spoon. While true, it's not very interesting from the perspective of the guys with bulldozers, front-end loaders and other heavy equipment. Received on Sat Jun 03 2006 - 02:21:05 CEST

Original text of this message