Re: theory and practice: ying and yang

From: mountain man <hobbit_at_southern_seaweed.com.op>
Date: Sat, 28 May 2005 05:01:36 GMT
Message-ID: <QWSle.3956$BR4.1783_at_news-server.bigpond.net.au>


<gnuoytr_at_rcn.com> wrote in message
news:1117162629.087907.31660_at_f14g2000cwb.googlegroups.com...
> mountain man wrote:

>> "Alfredo Novoa" <alfredo_novoa_at_hotmail.com> wrote in message
>> news:sfj89150l0t58h9vsi359ur958cj348jtl_at_4ax.com...
>> > On Wed, 25 May 2005 08:19:10 GMT, "mountain man"
>> > <hobbit_at_southern_seaweed.com.op> wrote:
>> >
>> >>IMO theory and practice are two sides of the one coin,
>> >>two views into the one reality.
>> >
>> > Of course, but this is rather contradictorial with many of your
>> > previous posts.
>>
>>
>> Really?  Is it not possible that a person can consider
>> multiple points of view, or must one consider just one
>> POV?
>>
>>
>>
>> > Where do you want to go with this?
>>
>> Consider that:
>>
>> 1) Current (RM) theory has not substantially changed in 30 years
>

> Special Theory of Relativity, about 100. still managed to incinerate
> 200,000 Japanese in about 10 minutes, total.
>
> Pythagoran, about 2500. still useful.

The pythagorean was required by Einstein, and there is more than reasonable claim by the ancient Indians for precedence to the Pythagorean.

>> 2) The practice-environment of DBMS theory has substantially
>>     changed in this time, in fact one might be entitled to claim it
>>     has changed by a quantum leap --- in the use of RDBMS
>>     software (ie: built in accordance to the principles of the RM).
>

> leap over a precipice, maybe. the XML weanies are leading that charge
> with a method which is yet older AND has the virtue of providing less
> functionality. go figure. same for the Pick-ininies.

I dont claim to understand the theory of quantum mechanics but I have written a "Brief History of the RDBMS and IT Management". http://www.mountainman.com.au/software/history/

It is not meant to be complete. It is simply a perspective based on the experience of changing technology over the last 20 odd years from the production floor of mid-range to large database systems.

The perspective is _not_ theoretical, but is based on experience in IT management of this environment, and a career of successful implementations and developments, at many scales.

My vision is simplification of systems. Presently, and since 1979 we have the following software environment (related to databases):

E0 - hardware
E1 - operating system and network OS
E2 - RDBMS (Oracle,DB2,SQL Server)
E3 - application software (and related program development tools
        and methodologies).

This is the simplified software protocol stack.

The final chapter of that history reveals a tool and a method whereby the environment can be reduced to the following:

E0 - hardware
E1 - operating system and network OS
E2 - RDBMS (Oracle,DB2,SQL Server)

All application software is in the form of RDBMS stored procedures resident in the E2 environment. E3 does not exist any more.

Admittedly this is quite radical, but it is easy to see that such an arrangment has enormous cost benefits. (See the chapter on Change Management).

>> 3) Date openly admits that current (RM) theory is not understood
>>     by database professionals.
>

> the same cannot, in general, be said of those who hold a certificate
> as Professional Engineer in any of our United States: for that you
> have to demonstrate that you actually know your s**t.

Yes, there is this issue of theory and practice being two sides of the same coin.

>> You tell me what the implications are.
>

> coders hate to be "constrained" by data which is smarter than they
> are.

It's all about protocol dude,
as you probably know.

My coders of application software are coders of SQL alone. They code directly in SQL, creating suites of stored procedures in the database. The contraints live in this same environment.

I too hated to be constrained by the constant need to refer to the central database, so I built a tool to bring *everything* inside the database system and so unify all endeavours within one and one only software protocol. (SQL)

-- 
Pete Brown
IT Managers & Engineers
Falls Creek
Australia
www.mountainman.com.au/software
Received on Sat May 28 2005 - 07:01:36 CEST

Original text of this message