Re: OOP - a question about database access

"Bob Badour" <bbadour_at_golden.net> wrote in message news:<k6KdnUriUJF8VjqiRVn-tg_at_golden.net>...

> Alfredo, a dbms is a system. An SQL compiler is an application. A DBA tool
> is an application. A server console is an application.

Agreed, I meant the DBMS server.

> > What is beyond RAD applications?
>
> BAD? (brittle application development) DAD? (delayed application
> development) FAD? (feeble application development) LAD? (leisurely
> application development) MAD? (misguided application development) PAD?
> (pokey application development) SAD? (slow application development) TAD?
> (tardy application development)

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.

> > > > The DBMS option is the only sensible if you need more than trivial
> > > > data management capabilities.
> > >
> > > There is a whole world of applications beyond data display.
>
> Agreed. Some applications exist to manipulate data without user intervention
> or external interfaces. How many applications neither manipulate nor present
> data?

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?

> > > >>One may use OO to implement the persistence access subsystem or layer,
> > > >>but that view will be quite different than the business view.
>
> But why the hell would anyone want to do anything so stupid?

For me what is harder to understand is that it is virtually impossible to convince OO fans about that it is an horrible blunder.

Dijkstra would say that OO damages brain :)

> > > Of course. But that doesn't mean the application needs to know which
> > > one is being used or be affected if one changes one's mind later and
> > > swaps in another.
>
> I disagree. At some level, the application must absolutely know what
> technology it uses; otherwise, how the hell can it use it?

Indeed. It is trivially true.

> > Data warehouses are only a special kind of databases.
>
> Actually, I consider them only a part of a single database. When you think
> of it, they are nothing more than snapshots.

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.

If you consider this a single database or two databases, is rather subjective IMO.

> > > >>That application of invariants leads to things like JDBC/ODBC/SQL that
> > > >>largely hide the mundane details of the mechanisms through automation.
> > > >
> > > > JDBC/ODBC are bridges between the application and the DBMS.
> > > >
> > > > SQL is the communication language between the application and the
> > > > DBMS, and it is also the database design language. SQL has three
> > > > parts: structural, integrity and manipulative.
> > >
> > > But they are all infrastructures provided to decouple the application
> > > from direct communication with the DB engine.
> >
> > No, they are provided to communicate the presentation application with
> > the DBMS.
>
> I cannot make much sense of either of your positions above.

I meant that you need some interface to communicate the application with the DBMS. JDBC and ODBC are for that.

> > If you talk about the communication layers like ODBC, ADO.NET, etc. It
> > is rather easy to change one for the other. You only need to touch few
> > code lines if any.
>
> My first question is: Why are any of them necessary?

Because we need to communicate the applications with the DBMS.

What solution do you propose in order to avoid ODBC, JDBC, etc?

Custom interfaces?

> Why do we persist in
> using such primitive computational models for application development in the
> first place?

Because we don't have many options.

Which computational model do you propose for application development? I am really interested about this.

I tried with declarative presentation rules, but the result was always worse than the simple drag & drop.

> > > My issue is about decoupling at a higher level than the DB engine. The
> > > application solution needs to be independent of those assumptions.
> >
> > Independent to the data model?
> >
> > This is an absurd.
>
> Higer level than predicate logic? That part is even more absurd.

Indeed.

> > > One then
> > > takes advantage of the automation providing such infrastructures by
> > > using those sorts of paradigms /within/ the subsystem or layer.
>
> What automation? Data independence?
> What infrastructures? The DBMS?
> What sorts of examples? ?
>
> Lahman is talking nonsense.

Of course he is talking nonsense.

The his approach consists basically in managing data in the applications using main memory network data structures, and the creation of a common interface to several file management systems in order to make persistent the main memory data structures.

He consideres SQL DBMSes, OODBMSes, XML file managers and OS file managers as basically the same: file managers! (or persistence mechanisms in his ill terminology).

The automation he wants to provide is that a single procedure must store the main memory data structures in: a SQL Database, a binary file, an XML file, etc.

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.

Regards
  Alfredo Received on Wed Nov 05 2003 - 13:53:14 CET