Re: In an RDBMS, what does "Data" mean?

"Eric Kaun" <ekaun_at_yahoo.com> wrote in message news:ZFmsc.19998$952.13933_at_newssvr31.news.prodigy.com...
> "mountain man" <hobbit_at_southern_seaweed.com.op> wrote in message
> news:UXvrc.1683$L.1212_at_news-server.bigpond.net.au...
> > "Eric Kaun" <ekaun_at_yahoo.com> wrote in message
> > news:bYnrc.19598$D33.8008_at_newssvr31.news.prodigy.com...
> > I see value in avoiding redundancies. All application code that relates
> > to database I/O that is external to the RDBMS environment requires
> > redundancy of definition of the database schema. This is so because
> > the entire system spans two software environments (E2 and E3).
> >
> > Current technology looks at this as the status quo. The world
> > is used to defining things in a union and conjunction of two
> > separate software systems. However it is very inefficient.
> >
> > When things can be defined using one software layer alone,
> > the redefinitions referred to above no longer exist.
>
> I agree, though using some fairly simple techniques definitions can exist
in
> one place, and be propagated to others. If an "object" could be defined in
> E2, for example, and automatically generate the appropriate changes on E3,
> how would that fit?

It would still imply replication of existent data, or if you prefer, redundant I/O in that updates would need to be pushed up from the database (E2) into E3.

However I reckon this would be a better "practice" to engineer as its operation relies on maintainance of the database, and avoids duplicate maintainance at the code level. It is a step closer to optimum running, for sure.

> I'm also curious why you suggest moving objects from E3 to E2 for reasons
of
> efficiency and duplicate elimination, but don't include E1 in the mix.
> Certainly services in E1 are relevant to applications?

First steps first. ;-)

Services in E1 and wheel-in wheel-out redundant services. An organisation uses these much the same way as the next. Their physical network may be different and their user base however, IMO, the elements of code resident at E2 and E3 are the uniquely specifying elements for that "organization's intelligence".

The first step in moving objects from E3 to E2 will obviate the (database application's) client environment of code.

This is the big mixmaster in complexity with the reality of the management of RDBMS production sites, the most expensive, the least responsive, the change-management headache, the cause of the bulk of many problems.

Binding the results into E1 should fall out of the consolidation effort (E3 to E2) and represents the logical next step in the theory of database systems, imo.

Pete Brown
Falls Creek
Oz

>
Received on Tue May 25 2004 - 12:42:27 CEST