Re: Development as Configuration

From: mountain man <hobbit_at_southern_seaweed.com.op>
Date: Fri, 06 May 2005 03:21:40 GMT
Message-ID: <8pBee.4388$31.92_at_news-server.bigpond.net.au>


"dawn" <dawnwolthuis_at_gmail.com> wrote in message news:1115340244.315952.260040_at_z14g2000cwz.googlegroups.com...
> mAsterdam wrote:
>> dawn wrote:
>>
>> > Alfredo Novoa wrote:
>> >
>> >>>Sure, there are other features that are important
>> >>>for DBMS tools, such as security and referential
>> >>>integrity, but many a software application has included
>> >>>code for those features too. To date it appears to me that people
>
>> >>>license DBMS tools for the PRIMARY, not negotiable, feature
>> >>>of having an API for creating, reading, updating, and deleting
>> >>>data on secondary storage devices,
>> >>>even if there are other important features
>> >>>too. Right?
>> >>
>> >>Completely wrong. The primary function of a DBMS is
>> >>to manage data and not to be misused as a file system.

You seem to have certain POV problems

Dawn's point is that once an organisation acquires (R)DBMS software (and/or tools) the business owner is free to utilise the machine itelligence in any way that he/she is capable of doing.

Sure it was built for database *systems* management but in today's world these systems have a host of features, and I could quote quite a number of instances where large organisations acquired a certain RDBMS software (SQL Server) because of its data transfer (import/export) services [and of course the automation thereof] alone !

There is no academic or theoretical standard of operation or indeed development of computerised intelligence.

All your POV is hammering is that of the RM pedagogy. You may as well just write an FAQ and point at it. It could have been written in 1979 because it has not substantially altered its scope since that time.

Make sure you reference the external oceanic expanses of ideas that exist in the world today, such as my article on why the RM of the data is sadly incomplete for any form of approach to current USE of technology.

>> > I'm not suggesting what the purpose is -- I saying what a primary
>> > requirement from the user's perspective it is meeting. There are
>> > DBMS's that are missing a lot of features, but I don't know of any
> that
>> > are deemed to be DBMS's and are missing a CRUD API. So, I would
>> > suggest that from the standpoint of someone who is looking for a
> DBMS,
>> > one feature they would not be interested in compromising on is
> whether
>> > it has a CRUD API. It is, I'll repeat, a primary feature for any
> DBMS
>> > product. Do you really disagree with that? If so, please provide
> a
>> > URL for a DBMS that is missing this feature.
>>
>> It is not a feature. In order to be able to manage the data, the
>> DSMS must assume there is no data traffic in or out of the database
>> outside the control of the DBMS. So, any DBMS _has_ to provide a
>> data manipulation interface.
>
> And just what do you call this capability that a DBMS product has that
> is not a feature of the product?

Generic database service-level tools: security, data transfer (export/import),
publication, subscription and replication, various logs, user and process activity queues, native programming language (SQL), operational issues (eg: backups. restores) and at the automation backbone a task scheduler capable of automating *anything* within the environment E2 (ie: RDBMS software - eg: SQL Server, DB2, Oracle, etc).

> It seems to me that providing this API is a rather
> important feature of the product, essential even.

One could argue it is helpful to visualise some form of protocol stack of software layers in relation to database theory. One such environment stack is:

E3: Application Software
E2: (R)DBMS software
E1: OS/NW software
E0: hardware - ROM software

----- physical layer

The API links E2 and E3 and, as you say, it is essential to the big picture. The FAQ response is that the RM is generic to all application software, and that is so because the RM is currently introverted because that was the requirement at the time the RM was put together.

That introversion enabled focus of relational DBMS capabilities, and essentially boot-strapped the modern RDBMS software that emerged from 1979 onwards.

So, in summary, when I think of an RDBMS product (such as Oracle, DB2 or SQLServer) I think of a software layer operating in a stack as described above and thus part of a greater environment (of software).

The RM of data must at some stage give way to a model of computerised intelligence, because there is no doubt that this is what is being purchaced at a (development) cost.

If the RDBMS software layer is capable of performing routine file system tasks at off-peak hours maybe at 2:00 AM every night as coordination with the job scheduler, will CJ Date call around personally at that hour and prohibit it because it is against the theory?

I dont think so ;-)

But I am not too sure about Alfredo.

Pete Brown
Falls Creek
Oz
www.mountainman.com.au

QuoteForTheDay:

                        "Big whorls have little whorls
                         that feed on their velocity,
                         and little whorls have lesser whorls
                         and so on to viscosity."

                         -  L.F.Richardson
Received on Fri May 06 2005 - 05:21:40 CEST

Original text of this message