Re: Relational database & OO

Responding to AndyW...

I agree with the solution, but I really think one is talking about a
Persistant Storage Engine (PSE) rather than perhaps an OO database. A
PSE can often be implemented using an object schema or RDB model.

That's fine. In fact, it is one of the advantages of the approach I proposed. It really doesn't matter to the time management problem solution whether the data is persisted in an RDB, an OODB, flat files, or clay tablets. The persistence mechanisms are fully encapsulated in the DB Access subsystem. So one could regard the DB Access subsystem I proposed as being a PSE from the perspective of the problem solution.

Among other things, that allows one to change one's mind about how the data is stored without having to touch the problem solution in any way. All one needs to do is replace the DB Access subsystem underneath the same subsystem interface.

Another advantage is reuse. Once one starts to abstract a DB Access subsystem for, say, the RDB paradigm, one quickly realizes that the abstractions are things like Schema, Table, Tuple, Query, etc. that are quite generic. So one can reuse the DB Access subsystem across applications with relatively little extra effort. (All one needs is an identity mapping between the problem solution and the RDB artifacts, which is easily described in configuration data for a particular application.) In fact, RAD IDEs are based upon exactly that sort of problem-independent reuse.


I would agree but again to me its still really at the end of the day
talking about relational issues ant not OO ones. Persistance to me
immediately evokes the need to be storing data - once that separation
is made, then one I think is in the relational world, no matter what
else they choose to believe (although this is not a bad thing).

I argue that the DB Access subsystem needs to deal with the particular persistence mechanisms that are at hand. The abstractions one needs to do that will be different for flat files (file/Line), RDBs (Table/Tuple), OODBs (Object/Relationship), or whatever. The situation is analogous to a UI where one uses Window/Control abstractions for a GUI and Page/Section abstractions for a browser. In addition, one needs to optimize differently for each paradigm and appropriate abstractions facilitate that.

However, within the context of a particular persistence paradigm, one should be able to provide subsystem reuse across all applications that happen to use that particular persistence paradigm. OTOH,...

I would also argue that modern RDB or OODB engines are not as portable as the vendors would have us believe. Each vendor has their own SQL extensions or whatever. And they each have their own unique quirks that need to be addressed in the way the data is accessed for optimal performance. So even when one just changes vendors within the RDB paradigm or the OODB paradigm, one may have to do some tweaking and that should be isolated from the problem solution code.
</aside>


I agree with the portability thing to be honest, unless the database
is kept very simple and genereric, its often better to just have the
simple API that sits on top of a plug-in architecture.

I sometimes use CORBA IDL to describe a problem because I can look at
it from the client side and see the OO and business mechanism being
expressed or I can look at it from the implementation side (server
side if you will) and see the often non-OO details.

Here is a basic example that you may find in a customer care &
billing system.


Module CustomerAccount {
typedef float Account_balance;
typedef float Amount_value;

interface Account { exception NoFunds {...}
exception TransactionError {...]

void Withdraw( in Amount_value someAmount ) raises NoFunds;

void Deposit( in Amount_value someAmount )
raises TransationError;
}

interface ServiceAccount : Account {...}
interface ConsumerAccount : Account {...]

struct AccountDetail {
Customer customer;
AccountType typeOfAccount
Account account;
etc.
}
typedef sequence<AccountDetail> customerAcounts;
}

I've left out the customer definiton, but in all general purposes its
a list of client accounts, each one contains a customer (billing and
contact details) and an account (which can be of any type depending on
your business structure.

Now, from the implementation side - there is no persistance, thats
where the OO side of things really shines thru. The developer in
america or the one in japan who may be implementing this have no
knowledge of the technical detail behind the interface they are
looking at. All they see is business functions (in their programming
language of choice).

This is the level that I prefer to work at - in other words - I sweat
the detail later and to me is a benefit of OO.

That's fine too. Note that the DB Access subsystem is free to use such generic mechanisms. That would make the DB Access subsystem even more reusable -- so long as one doesn't run into a situation where CORBA isn't available. B-) The advantage still remains that the subsystem interface is defined in terms of the particular application solution's needs and doesn't even have this level of dependence on the persistence access mechanisms.

However, the developer who is working on the implementation side
(unfortunately and confusingly called a server in corba terms) which
may be located in the UK, gets to see the detail behind the scenes.
Now they may be using a persistance storage engine, it may be a
relational database, or, if a telco solution, it actually may be an
interface to a real time billing system and may not have a database at
all (thats in this context).

Now from the client side point of view, they may be just trying to get
a list of customers who belong to a business entity, display the list
on the screen, then allow the CSR to see that customers real time
billing detail. The programmer may figure that the customer data has
come from a local database, but might not be aware that the $59.50c
that the customer currently owes is produced by a real time billing
sytem over in Hong Kong (ok, I know it will be slow - this is just an
example).

From the server side, its time to sweat the detail - this is where the
plug-innable architecture works for the server side stuff. What brand
of RDB/ODB cluster is used and how its used, or if another system is
being interconnected to (and requires an interface in SOA terms). It
doesnt even have to be an OO system at the back end. Procedural or
RPC functions may be good enough.

But that performance hit is important, especially on the server side. There is no free lunch and the more one abstracts things the more overhead one pays for dealing with all possible contexts. That's why full code generators for OOA models usually produce C code rather than OOPL code and why a simple message-based interface will run rings around the sort of remote object access one can get with interoperability infrastructures like CORBA. In the end one needs to make informed trade-offs between developer convenience and overhead. Often Moore's Law pushes those trade-offs towards the convenience side, but not always.

To answer the orginal question, to me, working with an OO database is
like working as the client programmer in the example above. Using a
relational database to me is like being the server side programmer in
the above example. Two conceptually different ways of thinking about
the same problem - neither is wrong, but each has its time and place.

Its for that reason I'm not keen on really going down the OODB is
better than RDB etc(although I do like that debate for fun). To be
honest, its important to select the correct technology for the problem
being solved and to do that, one has to be aware of the strengths and
weaknesses of each - perhaps by doing some product evaluation first or
by doing some small pilot projects, or even using a mix of both. I
would suggest bias if one is going down the x is better than y path,
and that isnt all thats best for the customer.

I think RDBs and OODBs have different niches. One should use the tool that is best suited to the application's needs. However,...

As to why these technologies are not as pervasive as they perhaps
should be. I would suggest that it would be more to do with the
number of people who develop large scale customer care and billing
systems vs the number of people who develop single user applications
that run on PCs. There isnt much of a demand for enterprise level
architecture on the desktop so the latter group of developers are not
really going to generate that much demand as they would for the more
simple to understand technologies.

I agree that RDBs dominate because of the nature of the IT market. The same data is commonly used in multiple problem contexts, which makes RDBs a good choice since they shine for ad hoc queries that are independent of any particular problem context.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@xxxxxxxxxxxxxxxxx for your copy.
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



.

Relevant Pages

  • Re: Relational database & OO
    ... The RDB Data Model and the solution's Class Model will typically be different for non-CRUD/USER applications because they need to be optimized differently. ... So one could regard the DB Access subsystem I proposed as being a PSE from the perspective of the problem solution. ... I've personally watched the paradigm for persistence changing from paper tape/punched cards to flat sequential disk to ISAM to CODASYL to RDBs to OODBs. ...
    (comp.object)
  • Re: Help! Difficulty understanding DB -> Object mapping
    ... Solve the customer's problem first and then worry about how objects in that solution will map into tables in the RDB. ... If addresses are stored in a separate table, then the Customer_Address_ID should be in the Customer table, not the Order table. ... Product, not the OrderLineItem. ... access subsystem to properly access the RDB to obtain the information, ...
    (comp.object)
  • Re: Help! Difficulty understanding DB -> Object mapping
    ... > The first thing to do is forget about what the RDB looks like. ... > depends on the Customer identity, ... > Product, not the OrderLineItem. ... > To do that the persistence access subsystem needs to know more about ...
    (comp.object)
  • Re: Help! Difficulty understanding DB -> Object mapping
    ... If addresses are stored in a separate table, then the Customer_Address_ID should be in the Customer table, not the Order table. ... That's because things like product descriptions are unique to the Product, not the OrderLineItem. ... That allows you to address performance problems in RDB access in that subsystem or layer so that it does not affect your problem solution logic. ... The persistence access subsystem needs to map that notion of Order into the actual tables in the RDB. ...
    (comp.object)
  • Re: Business Entities in the UI
    ... between the RDB and the UI, then you can ignore the rest of this ... significant problem for the customer so that display and persistence are ... Customer might be relevant abstractions for the solution; ... encapsulated in its own subsystem (for CRUD/USER applications they are ...
    (comp.object)