Re: SQL

In article <1138195462.008170.121310@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Alfredo Novoa <alfredo_novoa@xxxxxxxxxxx> wrote:
>Hi,
>
>Christian Brunschen wote:
>
>>The relational model, and SQL, were developed specifically for persistent
>>databases.
>
>Wrong, the Relational model was created for databases, persistent or
>not.

I think that you will find that the term 'database' at the time tended to
refer primarily to persistent data. If you read Codd's original paper,
available at <http://www.acm.org/classics/nov95/s1p1.html>, you will see
that he refers to 'records of a file' in a number of places. While the
paper is written in very general terms, it is clear that persistent 'data
banks' were in the forefront of his mind.

>On the other hand persistence is something relative.
>
>>I agree that code does some things better and DB other things, and one
>>uses them *together* in a Yin-Yang fashion. They compliment each other.
>
>DBMS are for data management (business rules) and code application is
>for presentation and communication.

That is one of _several possible_ ways to partition the responsibilities,
but it is certainly _not_ the 'one true way'.

>>Relational Databases and SQL are tools for the specific task of storing,
>>accessing, modifying data
>
>And to enforce data integrity and to derive new data (calculations).

The _fundamental_ purpose if a database management system it to store, and
allow the retrieval and modification of, data. As they have developed,
people have started adding more and more other functionality into database
management systems, but those are not part of the fundamental use of a
database management system.

As long as the database does its fundamental job, that of allowing access
to the data, all the other things can be done within the application.
These days, as saome database management systems have been extended to
include languages for stored procedures and similar, a lot of that work
could indeed be done in the database - but just because it _could_ doesn't
necessarily mean it _should_.

>> - they are single-purpose tools
>
>Indeed, its purpose is data management, any data management. Thats why
>they are called Database Management Systems.

_all_ programming is about 'data management' in one way or another.
According to you, then, every computer in existance would be a 'database
management system' ?

Actually, if one looks at the latest SQL standard, it does indeed look
like it defines a complete computing environment, somewhat centered around
a relational data model. However, this doesn't suddenly make all other
programming environments 'obsolete' or somehow dictate that everything
that the 'database management system' _could_ do, _must_ be done in it, in
the way that you appear to suggest.

>>A 'general-purpose' programming language is
>>one that allows one to write solutions to essentially arbitrary problems
>>using it, possibly with some specific exceptions (such as, 'python is a
>>general-purpose programming language, but due to its interpreted nature,
>>it shouldn't be used for writing interrupt handlers').
>
>In the same way, general purpose programming languages should not be
>used for data management (business rules included) because there are
>far better tools for this called DBMS.

You're forgetting something here. The part of the RDBMS that allows you to
define arbitrary business rules _are_ 'general purpose programming
languages' which have been added to the fundamental core of relational
database management systems. All you are advocating is that it should be
done under the auspices of the RDBMS, rather than within an application
that simply uses an RDBMS as a resource.

It _may_ make sense to put some, or all, or none of a system's business
rules into the database management engine, whether as constraints, or
triggers, or stored procedures. It all depends on the overall system.

>>One thing to remember is that a RDBMS does _not_ do _anything_ that one
>>can't do in code on one's own
>
>Do you mean something like to show windows controls?

No, I mean that whatever a RDBMS can do, I can write in code of my own.
That is how RDBMS:es are written, of course - in general-purpose
programming languages.

>> - they are essentially just a pre-written
>>library, with a little domain-specific language as part of its interface -
>>whereas on the other hand, _most_ of the things you can fo in _code_,
>>_cannot_ be done in an RDBMS.
>
>Nonsenses. DBMS must be extendable.

Actually, no. A DBMS that focused entirely on storing data and letting you
access and modify it, can do quite well. Witness the success of MySQL,
which only recently has gained things like triggers and stored procedures.
Yet many used MySQL for the pure storage aspect, and implemented all their
business logic within the application - and successfully so.

>You can do any data processing with
>a DBMS

.... only because database vendors have started adding general-purpose
programming languages to database management systems, even though they are
not fundamentally a part of the relational model.

>>Procedural, funtional, object-oriented languages are all _general-purpose_
>>tools for programming computers, for writing essentially arbitrary
>>programs.
>
>OO languages are procedural or functional.

Um, no. If you don't know the differences between procedural, functional
and object-oriented programmign languages, I suggest you read up on them.

>> SQL _isn't_. If it were, then why do database vendors create
>>languages to extend or 'hook into' the database (Oracle's PL/SQL), or
>
>PL/SQL is a replacement for PSM, the procedural part of ANSI SQL. ANSI
>SQL is also Turing complete.

Cool, there is now a _standard_ language with which the relational model
has been extended - much like different database vendors have, for some
time, added their own pet languages to RDBMS:es (PL/SQL in the case of
Oracle). However, this doesn't change the fact that the basics of SQL -
the data definition and query parts, which are the ones that have been
around the longest, and are the ones that actually have something to do
with the relational model - aren't turing complete, or general-purpose.
Just calling an arbitrary language 'part of SQL' doesn't change the
underlying relational model.

>>And again, 3GL can be used to _write_ RDBMS; the converse is _not_ true.
>
>The converse is also true. I could write a compiler for a 3GL in ANSI
>SQL or Oracle SQL

.... only beacuse 'SQL' these days has been extended to encompass things
vastly outside its original scope.

Basically, the term 'RDBMS' has been extended and expanded over the years,
until now it has become essentially a 'complete programming environment
based loosely around the relational model'. This doesn't change the fact
that those extensions and additions are indeed extensions and additions,
and not part of the fundamental purpose of a database management system.

>Regards
> Alfredo

Best wishes,

// Christian Brunschen

.

Loading