Relational Database

I'd like to draw your attention to a short article I found very interesting,
about databases in general and RDB in particular. I use MySQL quite a bit
and find it to be very responsive and, for a free product, excellent.

As some of you know I have been reticent for some time about the wisdom of
embedded SQL, and I see it as coming to the end of its usefulness. This
raises the question: "So, if we don't embed DB connections into our code,
how SHOULD we access databases?"

I think some of the concepts surrounding this are covered in the article.

http://www.drdobbs.com/database/202802994

Pete.

--
"I used to write COBOL...now I can do anything."

On Tue, 18 Dec 2007 12:19:17 +1300, "Pete Dashwood" <dashwood@removethis.ent
ernet.co.nz>
wrote:

>I'd like to draw your attention to a short article I found very interesting
,
>about databases in general and RDB in particular. I use MySQL quite a bit
>and find it to be very responsive and, for a free product, excellent.
>
>As some of you know I have been reticent for some time about the wisdom of
>embedded SQL, and I see it as coming to the end of its usefulness. This
>raises the question: "So, if we don't embed DB connections into our code,
>how SHOULD we access databases?"
>
>I think some of the concepts surrounding this are covered in the article.
>
>http://www.drdobbs.com/database/202802994

Most databases, as well as the SQL Standard, have the things Jim Starkey wis
hes for. They
have column level security. They all have one type -- NUMERIC -- that deals 
with numbers
of any size. To keep old timers feeling useful, they let you put a size on i
t, NUMBER(5).
The (5) is just an edit check to insure new values are not too big. Inside t
he database,
all NUMERICs are stored the same way. In other words, changing (5) to (6) do
esn't require
any database reformat.

They all have VARCHAR for variable length strings.

For recursive tree structures, Oracle has START WITH,  CONNECT BY and PRIOR 
(link in
parent). It's not in the Standard, but I believe others have comparable exte
nsions.

For application code closer to the database, the '03 SQL Standard FINALLY de
fined a
PL/SQL-like language (SQL/PSM) for stored procedures, and managed external p
rocedures
written in any language (SQL/CLI). Nearly all major databases already had th
em before the
Standard.

I dislike stored procedures for administrative (political) reasons. They usu
ally wind up
in the DBA domain rather than in application development. The external kind 
don't cause
that objection because they're not stored in the database, only a prototype,
 and DBAs have
no interest in  application programming languages such as Cobol, C, Python, 
PERL, etc.
They do present a security risk on some databases (e.g. Oracle), because the
y run under
the DBA's userid.