Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: The wisdom of the object mentors

Re: The wisdom of the object mentors

From: <frebe73_at_gmail.com>
Date: 26 Jun 2006 23:21:17 -0700
Message-ID: <1151389277.167986.83470@75g2000cwc.googlegroups.com>


> >> Changes to applications
> >> have much to do with behavior and formatting, and not so much to do
> >> with data.
> >
> > If we change the data, lets say we add a new column, phoneno, to the
> > customer table, doesn't the application need to change?
>
> Not all applications using the customer table may need to use each
> column of the table, so: not necessarily.

Using a coupled (embedded SQL) approach, it would be even better. Only the applications that want to use the new column (phoneno) need to be changed. All other applications (and SQL statements) are unchanged.

> >> Since the forces that change databases and applications are
> >> different, and their customers are different, they should be
> >> designed for these different environments and constraints.
> >
> > What are the forces to change databases that would not also force
> > you to change the application?
>
> One of the applications using the same database may be the force to
> change the database, while the other applications may not be. Or even
> the idea to historize data for future use without immediate need to
> use in an application at this point in time.

Yet again, using a coupled approach, only the applications that need the change will need to be changed. In what way will these kind of changes be easier if the application and database is "designed for these different environments and contraints"? You have showed a number of examples there a coupled design would be equal or better, please give some examples there a decoupled design would have any benefits.

> >> If, on the other hand, the applications are designed to be independent
> >> of the database structure, then the applications can use whatever data
> >> structures are appropriate for their algorithms.
> >
> > A algorithm could must obviously know about the data structure.
>
> Not at all! I'm currently writing many algorithms that get their data
> passed in as java objects. The algorithm does not need to know where
> the data came from and how it is stored in the database.

Doesn't java objects have a (data) structure?

If the algorithm knows about the database schema, it still don't know where the data came from or how it is stored. The DBMS hides that.

> It is very nice that I can test my algorithms by feeding it all kinds
> of data that do not need to come from the database. Some of the
> algorithms are used with local data (fed and the output is written
> back), but also with remote data when called through corba. I am very
> happy that my algorithms don't know at all the original data
> structures. Of course they have some data structures private to them
> internally.

There are many examples of lighweight and embeddable DBMS that could be used as "local data". Whether a database is local or remote is not hard-wired in the application.

Fredrik Bertilsson
http://frebe.php0h.com Received on Tue Jun 27 2006 - 01:21:17 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US