Re: OOP - a question about database access

"Alfredo Novoa" <alfredo_at_ncs.es> wrote in message news:e4330f45.0311051636.e8f1aea_at_posting.google.com...
> "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.

Any triggered procedure. Month end. End of quarter. Year-end.

> > > 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).

I doubt Dijkstra would consider a division between applications and data management appropriate. I know he expressed skepticism regarding the division into conceptual, logical and physical.

> > > 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.

That's one view of the database. Another view of the database has all the prior information.

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

Other views.

> > > 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.

Or even with a powerful interface built on top of existing dbmses.

> > > 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 suggest you need to know a better vision of the future.

> > 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.

No, I mean an integrated dbms and application development tool where applications can have local relvars as well as local array variables and any other kind of variable, and where one can express applications at higher levels than currently.

In a sense, Dataphor uses this approach too purporting as it does to implement a valid D.

> > > 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.

Some user interface elements work better using arrays, but fortunately operations exist to convert between arrays and 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.

Why?

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

Doesn't this contradict the former statement?

> > > 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.

Indeed. Received on Thu Nov 06 2003 - 03:27:57 CET