Re: OOP - a question about database access

"Bob Badour" <bbadour_at_golden.net> wrote in message news:<ocWdnYBXE738kTSiRVn-sA_at_golden.net>...

> > RAD means that you can drag and drop visual controls in forms using
> > the mouse, but you still can do all the rest typing code.
> >
> > It is really practical for presentation applications.
>
> Is that what RAD means? I thought it meant any method for rapid application
> development.

IMO this is the common use of the term. It is used with tools like Delphi and Visual Basic. A more proper name could be rapid form creation. Beyond form creation there is not anything specially rapid in that tools.

> > Some application exist to acquire data without user intervention eg:
> > an interface with a seismometer, but IMO who should manipulate data is
> > the DBMS, not the applications. What kind of applications do you mean?
>
> I suggest the applications neither manipulating nor presenting data form an
> empty set.

I was asking for an example of application that does not present, communicate or acquire data.

> > Dijkstra would say that OO damages brain :)
>
> Actually, he did not go that far, but he did not talk about OO in glowing
> terms either.

He probably was not aware of the pearls produced by the new generations of OO leaders like Ambler (one of the biggest proponents of the return to data managed in applications).

> > They are not necessarily snapshots. For instance the "operational"
> > database may represent only the data of the current year, and the
> > datawarehouse may represent the data of all the enterprise history
> > except the current month.
>
> How does that make the "data warehouse" anything other than a snapshot taken
> at the end of the previous month?

The fact of the "operational" database only has data about the current year.

Other datawarehouses hold the combined data of several "operational" databases.

> > If you consider this a single database or two databases, is rather
> > subjective IMO.
>
> The question is whether one wants to manage the data seamlessly. I suggest
> it makes the most sense to use a single database.

Agreed. Datawarehouses only have sense due to the limitations of the current DBMSes. With powerful distributed databases they would be unnecessary.

> > I meant that you need some interface to communicate the application
> > with the DBMS. JDBC and ODBC are for that.
>
> If one assumes a primitive computational model for creating applications,
> then I suppose that is so. Why make the assumption?

Because all the application development tools I know have a primitive computational model.

> I propose we abandon the primitive computational model for application
> development and describe our applications closer to the level of intent. If
> we do this, the whole issue becomes internal to a system comprising database
> management and application development.

Something like a customizable generic application that interpretates the descriptions?

I think that Dataphor uses this approach.

> > Because we don't have many options.
> >
> > Which computational model do you propose for application development?
> > I am really interested about this.
>
> D is a good start.

I agree.

Reference types and the other pointer based stuff should be dropped and relation variables should be added to application development languages, among other things.

We could represent the user interface description using relations.

> > I tried with declarative presentation rules, but the result was always
> > worse than the simple drag & drop.
>
> That will largely depend on what is available for declaration.

But it never will be enough.

Although the forms designed by draging and dropping can be easily translated to declarative propositions.

> > This incredible nonsense is very spreaded. There are hundreds of
> > thousands of people "working" in this way, and book stores are plenty
> > of junk books that preach this nonsense.
> >
> > IMO it is one of the biggest problems of the IT industry in our days.
>
> The problem exists at a lower level. Fabian is right that the problem lies
> in widespread ignorance of fundamentals.

Of course this is the source of the problem. I should say that "persistence" and "prevalence layers" are one of the worst manifestations of that widespreaded ignorance.

> Instead of correctly identifying
> that commercial dbmses need to provide greater data independence, the
> ignorant conclude one must have another 'layer' to whitewash the vendors'
> deficiencies. The problem with whitewash is the deficiencies still show
> through.

And with whitewash we return to data managed in applications using pointer based structures.

Regards
  Alfredo Received on Thu Nov 06 2003 - 01:36:05 CET