Re: Databases as objects

Neo wrote:
> <snip>
> Suppose we have a simple application that deals with 5 persons with the
> some attributes: name, age, ss#.
>
> One way to implement this is to create 5 instances of the person class
> in C++ where each instance has the desired attributes. The programmer
> needn't worried how the objects are stored and recalled as some mapping
> software takes care of that behind the scenes.
As long as that mapping software didn't impose itself on the DB design, I've no objection. As long as the DB's model can change, even trivially, without impacting the framework or the application, I've no objection. As long as that framework doesn't discriminate against languages or paradigms, and doesn't lock programming to a specific vendor's language or toolset, I've no objections.

> <snip>
>
> Another way is for a C++ application to connect to an RMDB and create a
> relation named T_Person with attributes name, age and ss#. Similar code
> might look like this:
>
> rs = ado.execute("SELECT * FROM T_Person WHERE name='john'");
> Print (rs.field("age"), rs.field("ss#"));
>
Here is what I think the first problem is: now the application has become dependent on the physical design of the database. It's dependent on the existence of a table named T_Person and that the table has the columns name, age, and ss#.

If this were an object, OO people would stand up and object to the C++ code's improper use of another object's private data. OO purists might insist that instead of violating the object's private data that getter functions should be used. But for some reason when that object is a relational database too many OOers silently violate the tenets of loose coupling and go right for the data with nary a twinge in their necks.
> Each of the above methods have advantages and disadvantages that make
> it more appropriate for a particular requirement. When you have two
> systems/methodologies at work, there is likey to be some type of
> impedance mismatch in feature, flexibility, performance, etc.
>
>
I don't see an advantage in the second example. The fact it works is its only benefit. If instead the code were modified ever so slightly as:

    rs = ado.execute("exec getPerson _at_name='john'");     Print (rs.field("age"), rs.field("ss#"));

Now we're using our application model's interface. As long as the interface remains the same our DBAs can go about tuning and designing without fear of breaking (at least) this line of code. Now it doesn't matter whether T_person exists or how getPerson is implemented--only that its interface remains consistent.

Does anyone really care how ad.execute() is implemented? Not as long as its interface is unchanged. Change the interface of ado.execute() and now everyone's interested.

That's what I'm trying to promote to OO people. The list of benefits is longer than that, but just as simple.

-- 
Visit <http://blogs.instreamfinancial.com/anything.php> 
to read my rants on technology and the finance industry.