Re: Searching OO Associations with RDBMS Persistence Models

On 2006-05-29 12:36:57 -0500, frebe73@xxxxxxxxx said:

What if we replace the database vendor? Must we rewrite all
the business rules?
What if we replace application programming language. Must we rewrite
all the business rules?

Yes, pretty much. Fortunately replacing languages is less frequent than replacing RDB vendors.

Currently changes in programming languages are
more frequent than changes in database vendor.

Disagree. There are COBOL programs that are 40 years old. There are C and C++ programs that are 30 and 20 years old. There is no RDB program that are older than about 20 years; and those wouldn't be compatible with today's engines.

Nothing last for ever.
Besides there are a high level of standardization between database
vendors.

And there's also a high degree of disparity driven by the fact that each vendor wants to differentiate itself from the other.


a DBMS is a bucket of bits with some low level rules to manage those bits.

How do you define low level?

At the level of the data structure elements. E.g. SQL knows about integers, strings, dates, etc. It knows about tables and rows. It does not know about any application objects.

Lets say we have a business rule saying
that the customer name must be unique. Implementing this rule in a RDB
would need less lines of code than implementing the same thing in the
application.

No, what you'd implement in the RDB is the notion that a particular string column would be unique. The RDB has no idea that this is the name of the customer.

In the application objects the code would KNOW that the field was the name of the customer and would ensure that it was unique semantically, not syntactically.

Normally something that takes few lines of codes is
considered high level, and something that takes a lot of lines of code
is considered low level.

I didn't know line count was the metric! So "HLT" must be very high level.

We can completely eliminate the DBMS and replace it with
another of an entirely different form (non Relational for example) and
still have all the business behavior we need.

Of course, but it would take a lot more lines of code. The same could
be said about programming languages or software engineering
philosofies. We can completely eliminate it and replace it with another
of an entirely differnt form (non OO for example) and still have all
the business behavior we need.

Or it might require a lot less code. Indeed, there are ways to eliminate the RDB and relace it with virtual files that is automatically persistent. Or we could replace the RDB with an ODB that takes very few lines of code to persist. Or... The point is we are not bound to a particular database implementation or scheme.

that the database is the heart of the system. This is flawed. The heart of the
system is the application code
Someting the databse is indeed the heart of the system. Sometimes it is
not.

It never is. Sometimes the DATA is the heart of the system, but the storage mechanisms is always a detail.

The database is a detail to be decided at the last possible moment and kept in a
position so flexible that it can be swapped out for another at a whim.
Why does the database need to be in a flexible position? Why does it
need to be swapped out at a whim?

It's called decoupling. It's one of those pesky principles of good software development. The less you are coupled to detailed mechanisms and implementations the better.
--
Robert C. Martin (Uncle Bob)  | email: unclebob@xxxxxxxxxxxxxxxx
Object Mentor Inc.            | blog:  www.butunclebob.com
The Agile Transition Experts  | web:   www.objectmentor.com
800-338-6716                  |



.

Relevant Pages