Re: the distinction between data and intelligence
From: Kenneth Downs <knode.wants.this_at_see.sigblock>
Date: Thu, 23 Jun 2005 07:55:31 -0400
Message-Id: <inkqo2-ot2.ln1_at_pluto.downsfam.net>
>
> ...[snip]...
>
>
> Part One of Two: semantics
> ===================
>
<snip>
>
>
>
>
> Agreed.
>
>
>
> Organisation, owner, management, workgroups (including IT), users,
> data, code and hardware.
>
>
> I am not so sure, consider the following ...
>
>
>
> While this is true, there is a most critical difference in the resultant
> environment to be managed. Rather than the code being spread
> across two software layers (E2 and E3) it may be defined once
> and for all within one and one only software (by SQL within E2,
> the native language of the database itself).
>
>
>
>
> In getting to the plateau, and from its summit,
> the approach to the mountain may be gauged.
>
> The journey goes on.
> Best wishes Ken,
>
>
>
>
>
Date: Thu, 23 Jun 2005 07:55:31 -0400
Message-Id: <inkqo2-ot2.ln1_at_pluto.downsfam.net>
mountain man wrote:
> "Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote in message
> news:e5boo2-6pg.ln1_at_pluto.downsfam.net...
>> mountain man wrote: >> >>> Thanks for the dialogue Ken ... >>> >>> "Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote: >>> >>> My dispute is with the term "intelligence". I just can't get past that. >>> Isn't it closer to the fundamentals to say they have established >>> procedures >>> around technology assets, those assets being hardware, software, and >>> data?
>
> ...[snip]...
>
>
> Part One of Two: semantics
> ===================
>
<snip>
> Part Two of Two: computers
> ===================
>
>>> E1: some operating system >>> E2: some (R)DBMS (and data). >>> E3: some application (code)
>
>
>>> Selection of some E1 is not regarded as "high-level" intelligence >>> but rather as a service for E2 and E3. >> >> Architecturally, yes. It is infrastructure.
>
>
> Agreed.
>
>
<snip>
>
> ...[trim]...
>
>
>> Here is a challenge, Pete. Force yourself not to use the word >> "intelligent" >> and then describe the collection of data, code and hardware. What terms >> come to mind? Before creating an abstract holistic description of them, >> define them individually and precisely, then see what description >> emerges.
>
> Organisation, owner, management, workgroups (including IT), users,
> data, code and hardware.
Now I would say that as far as computers go there is only data, code, and hardware.
>> >>> >>> I answer this question as follows: All database system invariably >>> have associated with this data a specific suite of database >>> application software (CODE). >>> >>> Traditionally this code was external to the database, but times >>> and technology are rapidly changing. Today, much of this code >>> (ie: E3 - application software code) may exists internal to the >>> (R)DBMS - stored procedures coded from SQL. >>> >>> To take matters to their extremes, I am able to demonstrate >>> http://www.mountainman.com.au/software/southwind/ >>> a database system in which 100% of the application code >>> is internal to the (R)DBMS - along with the data - in the >>> form of SQL (stored procs). >> >> For the above three paragraphs, I would contend you have mistaken a >> *plateau* for the *mountaintop*. As an implementation issue, being able >> to >> put code into the DB solves a crucial issue, it allows you to enforce biz >> rules on the server itself, allowing for no back-door to commit bad data. >> >> But this is only an implementation ability, it is not the final theory of >> coding.
>
>
> I am not so sure, consider the following ...
>
>> When you move the code into the server you carry with you all of >> the problems of coding, all of the version control issues, all of the >> need to match code to structure.
>
>
> While this is true, there is a most critical difference in the resultant
> environment to be managed. Rather than the code being spread
> across two software layers (E2 and E3) it may be defined once
> and for all within one and one only software (by SQL within E2,
> the native language of the database itself).
>
>
>> This is why you are only on a plateau, and the >> mountaintop yet eludes you.
>
>
> In getting to the plateau, and from its summit,
> the approach to the mountain may be gauged.
>
> The journey goes on.
> Best wishes Ken,
>
>
>
>
>
-- Kenneth Downs Secure Data Software, Inc. (Ken)nneth_at_(Sec)ure(Dat)a(.com)Received on Thu Jun 23 2005 - 13:55:31 CEST