Re: Development as Configuration

mAsterdam wrote:
> dawn wrote:
> > 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?
> >>>>
> >>>>...The primary function of a DBMS is
> >>>>to manage data and not to be misused as a file system.
> >>>
> >>>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
> >>>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? It seems to me that providing
this
> > API is a rather important feature of the product, essential even.

>

>

Probably -- I was using it in the dictionary sense of a "characteristic" and also intended that it be a feature desired by customers. In other words, if I were to list everything I would like to have in a DBMS, it would surely include the CRUD API.

I'm still not certain I understand your point, but it sounds like our difference in terminology might only be that you are suggesting that there are non-DBMS products that also provide the CRUD features (file systems) so that if that were the only feature that a customer desired, they need not seek out a DBMS.

In that case, we might be signing from the same hymnal (Gereformeerde, of course). I will also suggest that companies select DBMS tools these days when they have identified a need to store structured data, period.  If a developer or small group of developers need a CRUD API even for a prototype, they opt for a SQL-DBMS tool to provide such, whether or not they care about any other features. THAT is what I was trying to say. Agreed?

> The data manipulation interfaces (including the CRUD API)
> of a DBMS, are necessary to garantee it's datamanagement
> capabilities. It is a solution to a provider's need.
> The 'consumer' wants the datamanagement, so he submits to
> exclusively use the datamanipulation interface provided by
> the DBMS.

>

I think "feature" is more the dictionary term of "characteristic" while adjectives such as "required", "desired", "essential" can help identify whether a feature is a "solution" to some problem. I don't think that "solution" is inherent in the term "feature".

--dawn Received on Mon May 09 2005 - 18:51:08 CEST