Re: Changing database to SQL from DDS

----- Original Message -----
From: "Al Barsa" <barsa@barsaconsulting.com>
To: "Midrange Systems Technical Discussion" <midrange-l@midrange.com>
Sent: Tuesday, January 07, 2003 5:27 PM
Subject: Re: Changing database to SQL from DDS

> Skip Marchessani does a talk at COMMON on the differences in defining a
> database in SQL versus DDS, and I would say that all-in-all DDS does a
> better job.  SQL is trendy.  One of the reasons that System/38 databases
> were so solid was the existence of the DDS REF keyword, so that you could
> create a field reference file, and make all of the fields refer to each
> other.

au contraire, mon ami....

SQL is FAR from "trendy". It is the linqua franca of database. Period. You
work with other databases, you work with SQL.
As I, and others, have mentioned in many other posts, the reference
functionality is available in the tools that you use to design, modify and
create databases. Applied, it can be more consistent than DDS's REF
keywords. Solidity of the database comes from the architecture of the 38 and
400, not the definition language. I have seen both DDS and SQL abused.

> Much to IBM fault, in recent releases, they have enhanced SQL databases,
> but not DDS.  A prime example of this is EVIs (encoded vector indexes).

Fault? They said they would do it. They did it. Foreign key constraints...
the very thing that makes the database reverse engineering operations
possible, are not possible in DDS itself. You must use commands or SQL. And,
again, the tools shine here. Tie two files together and the foreign key
constraints are applied. Period.

> Regardless, unless you are doing something that can only be achieved in
> SQL, the final databases you get are comparable.

Comparable is an understatement. Outside of a few flag bits that indicate
the creation "source", and functionality that appears only in SQL, the
implementations are virtually identical.

As for your original question, converting "to" SQL is more of an
implementation at the code level with embedded SQL statements for access
(DAL, Data Access Language) replacing native I/O and sorts (FMTDTA) or
OPNQRYF commands.

You can choose to design and build in SQL DDL (Data Definition Language)
independantly of embedding it in programs. It's just that without invoking
the optimizer through DAL, you won't gain performance advantages produced by
creating the "perfect" (as Bob D calls it) index over the files. And
likewise, the programs that use logical files and native I/O would continue
to be dependant upon the existance of those logical files, thus hampering
index tuning operations. Tuning thus remains a programming chore and not an
independantly created index chore.


===========================================================
R. Bruce Hoffman, Jr.
 -- IBM Certified Specialist - iSeries Administrator
 -- IBM Certified Specialist - RPG IV Developer

"If you pick up a starving dog and make him prosperous,
  he will not bite you. This is the principal difference
  between a dog and a man."

    - Mark Twain