Re: SQL

In article <1138636452.149150.130280@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Alfredo Novoa <alfredo_novoa@xxxxxxxxxxx> wrote:
>Christian Brunschen wote:
>
>>>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.
>
>Indeed, it tends to, but it does not imply persistent data.

Something can be created _for_ a certain purpose, without being _limited_
to that purpose.

>>>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'.
>
>In the begining of computing age there was only a way: to develop
>business and presentation rules in the applications. DBMS were created
>later to solve the problems of such a primitive approach. The history
>showed that it is a lot better to use specialized subsystems to manage
>data instead of doing everything directly in the applications, and such
>a specialized and reusable subsystems are called DBMS.

Yes, but that still doesn't suggest that _all_ _business_ logic should be
in the DBMS, as you suggest.

>>The _fundamental_ purpose if a database management system it to store, and
>>allow the retrieval and modification of, data.
>
>Very very wrong. The fundamental purpose of a DataBase Management
>System is to manage data. That's why it is called DBMS. Simple, isn't
>it?

Let me quote from C.J.Date's 'An Introduction To Database Systems, Volume
1', fifth edition, 1990, specifically section 1.2 on page 5:

<quote>
1.2 WHAT IS A DATABASE SYSTEM?
To repeat from section 1.1, a database system is basically a computerized
record-keeping system; that is, it is a computerized system whose overall
purpose is to maintain information and to make that information available
on demand.
</quote>

>Data integrity is the most fundamental issue in database management.

Data integrity is _one_ fundameental issue, but not in fact the _most_
fundamental issue: the _storage_ and _retrieval_ of the data are _even
more_ fundamental - without those, there's no data whose integrity to
guard.

>>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.
>
>Wrong again. You are confusing what the very first database products
>were with what a good DBMS should be. Data integrity was very present
>in the mind of the first DBMS researchers.

Integrity in the most basic sense, that no foreign key should refer to a
primary key that does not exist, yes - those are the fundamental simple
referential integrity points that are indeed part even of E.F.Codd's very
first paper (where, however, he suggests that it may be better to perform
'consistency checking' as he calls it ona daily or evel less frequent
basis, if it is known that the frequencey of operations that might put the
database into an inconsistent state is small).

>Dbase III was not a DBMS, it was a primitive file processor.

I wasn't talking about Dbase in any version - what does that have to do
with anything?

>>_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' ?
>
>No, a DBMS must satisfy a list of requirements,

Indeed! This list is described, for instance, in thhe aforementioned book
by C.J.Date, in chapter 15 - specifically, section 15.7, which described
the 13 rules that are collectively known as "Codd's Twelve Rules", as well
as the "nine structural, three integrity, and eighteen manipulative"
features of the relational model (see pages 389 - 391).

>but for instance most
>"application servers" satisfy all them. On the other hand all DBMS are
>application servers.

None of the features required of an RDBMS according to the definition make
an RDBMS, or require an RDBMS to be, an 'application server'. Therefore,
your statememt 'all DBMS are application servers' is false.

>>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.
>
>Around a corruption of THE Relational Model. There is only ony
>Relational Model.

I was referring to the fact that most database engines available today
work on something which they refer to as a 'relational model', but which
is not the same as the strict and clear relational model as described by
Codd.

>> 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.
>
>Indeed, only the business rules must be implemented using the DBMS.

According to the definition in the book I referenced, there need be no
support for arbitrary business logic in a RDBMS. Therefore, demanding that
'business rules must be implemented using the DBMS' is simply silly,
because you can't expect a RDBMS to be able to handle arbitrary business
logic.

>The
>presentation and communication might be implemented in the
>applications.

Again, that business logic that goes beyond simple data integrity, may
well be better implemented _outside_ the database. Indeed it may _have_ to
be, because RDBMS:es are not required to be able to support arbitrary
business logic.

>>>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.
>
>It was not an addition. It is a requirement of the RM since the first
>day.

Where in E.F.Codd's paper does he mention anything about the 'data bank'
(to use his term) performing arbitrary business logic? The only thing
mentioned (towards the very end) is simple referential integrity checking
(which, as mentionned, he suggested could be done off-line, once evry day
or even less frequently).

>You are probably confusing again the RM with what primitive
>products like DBase were able to do.

Suffice it to say that you are incorrect.

>A DMBS MUST allow the creation of new types and procedures,

Not according to the requirements listed in 'In Introduction...'. It
_does_ list a requirement, in the mind of C.J.Date rather than Codd, for
the ability to create data types specifically for the purpose of defining
the _domains_ of the columns, but it says nothing whatsoever about
_procedures_.

>or classes if you prefer.

>>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.
>
>RDBMS are also resources, but they are application servers

Not according to Codd and Date ...

>intended to enforce and centralize the business rules.

intended to enforce referential and other data integrity, but not to
enforce general business rules (which might go well beyond mere integrity
of the data).

>>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.
>
>This is like to say that all that a 3GL can do, you can write in
>assembler, but a lot worse because if you enforce the business rules in
>the applications then you will have to repeat the work in every
>application.

.... unless, of course, you were to do something intelligent like, say,
collect the business logic in a framework orlibrary that can be used by
any application, at a higher levelof abstraction than talking to the
database. Or, for that matter, one could implement the business logic in a
sepparate tier, which exposes a high-level protocol to client
applciations, and which uses an RDBMS to store the data.

>And the abstraction level difference between Java and SQL
>is a lot bigger than the difference between assembler or bytecode and
>Java.

.... which matters how? Oneshould always work at the appropriate level of
abstraction. This means, among other things, that one shouldn't go down to
a lower abstraction level than necesssary; and it also means that if you
are going to be reusing something on a lower abstraction level in a way
that effectively expresses a higher-level abstraction, then it makes a lot
of sense to wrap that up and use that higher-level abstraction.

>The 3GL regressionists are very similar to the old assembler
>regresionists of the 80's.

>>Actually, no. A DBMS that focused entirely on storing data and letting you
>>access and modify it, can do quite well.
>
>This is not a DBMS, but a primitive file processor.

Well, according to C.J.Date and E.F.Codd, you're wrong about that.

>> Witness the success of MySQL,
>
>Currently MySQL supports stored procedures and all the typical features
>of a DBMS, but in the first versions MySQL was only a primitive file
>processor, and an important part of its success was due to the
>ignorance of the application programmers.

MySQL, even in its early incarnations, was a relational database
management system, though it was lacking in certain ways; but
fundamentally, it stored data in tables, made up of rows and columns, and
it used SQL to access and modify the data. True, it failed to offer ACID
transactions, and alot of other things, but it did offer the fundamental
data abstraction that the relational model is about. To refer to it as 'a
primitive file manager' suggests that you are trying to obfuscate the
issue.

>>Yet many used MySQL for the pure storage aspect, and implemented all their
>>business logic within the application - and successfully so.
>
>In this business any utter incompetent might be very successful.
>Specially in the consulting area.
>
>If you use 20 times the required resources but you solve the problem
>then your customer might be very satisfied. Success has little to do
>with efficacy in an intellectually enpoverished environment like this
>industry.

it may be more efficient, and use less resources, to put the business
logic outside the database.

>
>>... 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.
>
>If you read Date's definition of the RM you will see that it is a
>fundamental part of the RM.
>
>http://www.amazon.com/gp/product/0201612941/103-9549884-4286210?v=glance&n=283155
>http://www.amazon.com/gp/product/0321197844/ref=pd_sim_b_1/103-9549884-4286210?%5Fencoding=UTF8&v=glance&n=283155

Rereading Date's definition ('An Introduction...', fifth edition), I do
not see anything that supports the idea that putting general-purpose
programming language facilities into the database management engine 'is a
fundamental part of the relational model'. Quite the contrary! Would you
perhaps care to offer an actual quote?

I note that in the introduction to "Database in Depth: The Relational
Model for Practitioners" (which is available in PDF as a sammple chapter
from O'Reilly,
<http://www.oreilly.com/catalog/databaseid/chapter/ch01.pdf>),
C.J.Date specifically states,

<quote>
overall, the relational model isdeclarative, notprocedural, in nature;
that is, we favor declarative solutions over procedural ones, wherever
such solutions are feasible. The reason is obvious:declarative means the
system does the work, means the user does the work (so we?re talking about
productivity, among other things). That?s why the relational model
supports declarative queries, declarative updates, declarative view
definitions, declarative integrity constraints, and so on.
</quote>

>>>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.
>
>I know the differences better than most Wal-Mart book writters.
>
>Java is an OO procedural language and Common Lisp is an OO functional
>and procedural language.

Would you care to elucidate exactly what it is you understand that
terminology to _mean_ ?

>Regards
> Alfredo

Best wishes,

// Christian Brunschen
.