Re: Relational database & OO

Responding to Gagne...

Solving a time management problem is a quite different subject matter than persisting the relevant data. Solve the time management problem in you application first. Then, when you know what object attributes need to be persisted, define a suitable Data Model for the database. 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.

That's one way of doing it. My experience shows that 70-80% of a system is queries. Whether inquiry transactions or reports, all the business systems I've participated coding or designing spent little production time changing data. In the online systems I'm familiar with, update and change transactions were preceded and followed with queries. Long after transactions are done posting, management looks at reports to see how their business is doing. Given statistics like these it makes little sense to design your application or OO model before designing your database.

Note that I was careful to qualify with "non-CRUD/USER".

That sort of proportion is a symptom that the application is USER/CRUD processing. The application is basically a pipeline between the database and the UI and its main purpose in life is to convert between the two views. For that sort of situation the RAD layered model infrastructures already provide lots of automation so an OO approach would probably be overkill by reinventing that wheel.

Additionally, relational data models can be more easily proven correct--or correct enough--before an investment is made in coding.

I'm not sure I buy that. More easily than what? The RDM normalization can be applied beyond the RDB's table/tuple paradigm. ISAM files, CODASYL files, and other data representations can be normalized using the same basic rules. And OO Class Models are routinely normalized as part of the basic paradigm methodology.

However, I don't see that as being very relevant. My point is that the application's problem solution doesn't care how the data is stored. If it doesn't care how it is stored, it certainly doesn't care how the storage mechanism is validated.

Lastly, your database is language-neutral. It shouldn't matter what language the application sitting in front of the database is written in, or even what paradigm it's born from. Flexibility starts with a good database design and extends through the application--not the other way around.

That's true enough but I would make it even stronger. RDBs are designed to be problem-independent, not just language independent, which is pretty much my point.

The data structures one needs to optimize the solution to a /particular/ problem in an application are often quite different than the structures best suited to optimizing generic, ad hoc access of the same data. So if one is solving a non-CRUD/USER problem where special optimization is usually required, one wants to separate the views of the solution from those of the RDB.

In addition, the OO construction paradigm for solving individual problems is quite different. For example, in an OO solution there is no construct remotely similar to an RDB join. That's because OO relationships are instantiated at the object level rather than the table level, relationships are navigated differently, and the paradigm employs peer-to-peer communications.


*************
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
    ... can be applied beyond the RDB's table/tuple paradigm. ... relationships in an RDB represent a specific implementation of the ... But no existing production database qualify as a relational database. ... Neither do the relational model or SQL. ...
    (comp.object)
  • Re: Relational database & OO
    ... What is the "RDB's table/tuple paradigm"? ... Are you saying you don't know what an RDB table is or what ... But no existing production database qualify as a relational database. ... Neither do the relational model or SQL. ...
    (comp.object)
  • Re: Designing web form processing system
    ... > simply a pipeline between the UI and the database? ... a different paradigm to procedural and requires some shifting in thinking. ... > this part of the application is just accessing data from an RDB, ... don't really need one - just duplicate the functionality in the various ...
    (comp.object)
  • Re: Relational-to-OOP Tax
    ... If you're thinking of a CRUD system, ... No, I agreed that using a database for simple create, read, ... the design relative to using OO techniques, ... All this mixing paradigm stuff is irrelavent anyhow. ...
    (comp.object)
  • Re: Writing a DAL with TDD
    ... will use the database - which is what you advocated elsewhere. ... designing some new algorithm for a particular business scenario. ... you'll say that we "just" mock those things... ... talented developers, coupled with the strongest ...
    (microsoft.public.dotnet.languages.csharp)
Loading