Re: Databinding - Best Practice (object-oriented)

From: Alfredo Novoa (alfredo_at_nospam.es)
Date: 06/07/04 

Date: Mon, 07 Jun 2004 11:48:50 GMT

On Mon, 7 Jun 2004 09:19:32 +1000, "Grant Frisken"
<gfrisken.minusspam@optusnet.com.au> wrote:

>> No, you are wrong. The actual database structure is hidden by the SQL
>> DBMS. Your application code is not exposed to the internal data
>> structures used by the DBMS.
>
>I meant of course that your code is exposed to the relational model - which
>is in general a different way of looking at the problem domain then many OO
>designers would use.

And it is infinitely better for data management BTW. OO designers
should learn about The Relational Model, but many of them only know
what they readed in an OOD book's appendix written by a developer
without a grasp on data management theory.

This is a vitious circle.

OO is for application development only, not for Database Systems
development. Applications are only a part of an Information System.

A typical information system has one DBMS and several applications.
The design of the whole system is very different from the design of
one of the applications.

> This is not to say that it is necessarily better or
>worse - just different

No, it is a lot worse. What many OO coders do is to process the files
in the applications or in specific purpose DBMSs built by them. It is
a return to the 50's. General purpose DBMSs where created to solve the
problems of that primitive approach. You can read about this on any
decent database theory introductory book.

> - and when using object oriented design and languages
>there is an impedance mismatch between the two models.

Indeed, but the problem is in the OO languages that are not able to
handle tables directly. You can create array variables, but not table
variables and it is a big problem.

The problem is that most language designers knows nothing about
database systems.

> ADO.NET does
>nothing to address this

Yes it does. It maps the result of queries into objects, but it is
rather cumbersome. You need thousands of lines for trivial tasks. The
disconnected "architecture" is a big mistake.

ADO.NET is a clear backward step in ease of use, and it has important
problems if you want to map big tables.

IMO it is the worst part of the .Net Framework by very very far.

>, it just maps the relational model into objects

It is OK.

>which results, in my view, in a somewhat unnatural object oriented usage if
>you choose to use this model directly throughout your code.

Again OO is not for data management it is for application development
only.

OO is not well defined. It is very subjective to say that something is
a natural or unnatural use of OO. There are as many versions of OO as
practicioners.

On the other hand The Relational Model is practically unknown by the
vast majority of the OO developers. They know the basic syntax of SQL,
but they don't understand the model and the problems it was intended
to solve.

>> And all of them I know make great blunders. For instance most of them
>> identify tables with classes.
>
>This doesn't have to be the case. I've developed OO/Relational mappings in
>the past which allow much more sophisticated mapping then one class = one
>table.

one class = many tables and one table = many classes is as bad as one
class = one table.

The correct equation is:

one class = one domain.

Anything else is a great blunder.

See this for a detailed explanation:

http://www.amazon.com/exec/obidos/tg/detail/-/0321197844/ref=pd_sbs_b_1/103-0442475-8991033?v=glance&s=books

> I agree that the tools that attempt to auto generate a relational
>structure from an OO hierarchy based on such simple heuristics tend to
>produce very ugly and inefficient database structures

It is always a blunder to start with a hierarchical approach. The
hierarchical approach for data management was discarded on the early
70's because their primitivism.

Unfortunately many people continues to build their own specific
purpose network/hierarchical DBMSs misusing the SQL DBMS as a mere
transactional file manager completely hidden to the applications.

> (just as I believe
>direct mapping of a relational database structure into object oriented
>design tends to produce ugly object oriented code).

A good mapping tool should require no or very little code.

> The two layers, in my
>view, need to be designed somewhat independantly to maximise the strengths
>of both technologies.

Indeed. The database design must be done by a professional database
designer with a good knowledge of The Relational Model, and the
applications should be intended to present the data to the users.

>I see you have pushed this product several times - you wouldn't happen to
>have a financial interest in it would you :-)

No, in fact I am developing a similar product, but it is not finished
and I can not recomend it :-)

I believe in that approach.

>> As I said before all DBMSs already do that.
>
>You appear to come from a very strong DMBS background

My background is in OO, but I try to have a good background in
database management too.

IMO all the application developers must have a good background on data
management theory, but the reality is that most DBA's don't have it
and most coders don't have a clue.

> - which means that you
>are probably very comfortable using this model throughout your code.
>Others will prefer to work with an application model that is closer to the
>design modelling that they do (which typically will not include tables,

I am very comfortable with both, but one is clearly superior than the
other.

I solved the same problems using both approaches and the difference
was huge.

>relations and rows etc as first order objects).

Tables and relations are basically the same. A table is a 2-D
representation of a relation.

The name of The Relational Model comes from the fact of it is derived
from the mathematical concept of relation: a subset of the product of
several sets.

Loosely the objects contained in a table are relationed among them.

It is a shame that tables are not first order objects in OO languages.

Regards
  Alfredo

Relevant Pages

  • Re: Databinding - Best Practice (object-oriented)
    ... And it is infinitely better for data management BTW. OO designers ... should learn about The Relational Model, but many of them only know ... OO is for application development only, not for Database Systems ... The design of the whole system is very different from the design of ...
    (microsoft.public.dotnet.framework.windowsforms)
  • Re: O/R Mapper
    ... relational model build on entity definitions, ... database, often done by a person who's job it is to design the ... >> changes to the db can be cumbersome in a huge schema with lots of ... > I am not saying that your design doesn't have value; ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Relational model versus object model
    ... >>So your point is not that everything should be in the relational model ... >>but that everything should be in the database? ... > Only everything related to data management. ...
    (comp.object)
  • Re: Relational model versus object model
    ... >So your point is not that everything should be in the relational model ... >but that everything should be in the database? ... Only everything related to data management. ... Alfredo ...
    (comp.object)
  • C# programmer looking for a job
    ... Software Development including Desktop, Client/Server and Database ... Practical skills in object oriented design and design patterns ... XML, Oracle, CVS, VSS, Delphi, bug tracking. ... Developed in Delphi5; ...
    (misc.immigration.usa)