Re: Having difficulty refactoring a DB application

From: Fredrik Bertilsson (fredrik_bertilsson_at_passagen.se)
Date: 10/09/04 

Date: 8 Oct 2004 23:43:51 -0700

"H. S. Lahman" <h.lahman@verizon.net> wrote

> If it is a CRUD/USER pipeline, you should probably
> be using a RAD development environment rather then OO.
In this case, try http://butler.sourceforge.net.

> SQL is a very specific persistence mechanism
You must be kidding... SQL databases are by far most used type of
databases. The ratio (in usage) between SQL databases and non-SQL
databases is something like 95/5.

> your problem solution should not have to know about specific persistence
> mechanisms because...

Some people still dream about OO databases and argue that you should
make your application switchable to these databases in the future. But
making your application independent to database type, will cost you a
lot of time and effert. It is most likely that relational databases
will be the state-of-the-art type, during your applications
life-cycle. There are many examples of databases that have served
multiple generations of applications in COBOL, C, VB, Java, etc.
Examples of the opposite, applications that have been working with
different generations of databases, are very few.

> the OO solution is organized
> around behavior collaborations while the RDB is organized around static
> data relationships.
This is how software engineering have been described for about 40
years. You are modelling the data in the database, and the
functionality in the application. Or is it a difference in the
meaning of "behavior" and "functionality"?

> Finally, the application may be at a different
> level of abstraction from the RDB
This is a very common mistake in OO design. This will lead to a very
complex mapping between your objects and tables. Try to avoid this.

> The bottom line is that for large, complex applications outside of the
> pure CRUD/USER realm
As a matter of fact, many complex applications have a lot of CRUD
oriented functionality. Look at SAP R/3 and you will see many client
forms that almost directly maps to the database tables. So a CRUD
oriented tools should almost always be used in some degree. But also
in non-CRUD oriented functionality, a simpel mapping between tables
and objects should be used for minimizing complexity. The only thing
you need to add in your table objects is functionality for (column)
data validation and formatting/transformation.

> the solution abstraction will /invariably/ be
> different from the RDB and they will usually be significantly different
This is a very common argument from OO evangelists, but people outside
the OO world know that this is not true. Many projects have failed
because OO designers have made a OO model completely different from
the database schema. The problems with mapping these model together is
usually very big. And you have to remember that a OO application is
normally not the only user of a database. Mostly you also have
applications written in non-OO languages, report engines and
datawarehouse tools accessing the database. Only the OO-programmers at
a company will know how the object model looks like. Everyone else -
other programmers, report writers, testing staff, project managers -
will know the database schema.

Fredrik Bertilsson
http://butler.sourceforge.net

Relevant Pages

  • Re: Business objects, subset of collection
    ... might get faster applications than you would if you had used a SQL ... That is why databases using caching. ... there mainstream SQL databases wouldn't perform ... Lets say you want to find all unpaid invoices. ...
    (comp.object)
  • Re: Generic database dictionary access
    ... there is no generic access into the data dictionary ... >> of relational databases except at the table column level. ... constraints etc. but no such functionality currently exists ... As Mr. Fuhr has pointed out, there is an SQL standard for it in ...
    (comp.lang.python)
  • Re: Does Access Break?
    ... I specialize in adding new functionality to existing ... databases, making modifications to existing databases and fixing problems in ... and since the developer is no longer with our company, ... developer's programming to determine what he did and how he did it, ...
    (comp.databases.ms-access)
  • Re: Having difficulty refactoring a DB application
    ... SQL databases are by far most used type of ... > multiple generations of applications in COBOL, C, VB, Java, etc. ... > functionality in the application. ... > As a matter of fact, many complex applications have a lot of CRUD ...
    (comp.object)
  • Transfering tables, queries, forms and reports
    ... I have created several databases with some functionality for editing the ...
    (microsoft.public.access.gettingstarted)