Re: OOP - a question about database access

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

Is that what RAD means? I thought it meant any method for rapid application development.

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

I suggest the applications neither manipulating nor presenting data form an empty set.

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

Actually, he did not go that far, but he did not talk about OO in glowing terms either.

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

How does that make the "data warehouse" anything other than a snapshot taken at the end of the previous month?

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

> > > > >>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 one assumes a primitive computational model for creating applications, then I suppose that is so. Why make the assumption?

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

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.

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

D is a good start.

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

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

The problem exists at a lower level. Fabian is right that the problem lies in widespread ignorance of fundamentals. 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. Received on Wed Nov 05 2003 - 15:41:04 CET