Re: DBA Question

Hi Alan,

Are you commenting about the implementation of databases you have seen or
are you saying that a relational database cannot be implemented with DDS?

If the former, then you have been unfortunate (and you have my condolences
<g>). If the latter, then not so.

For a relational database we need to be able to define sequence, selection,
projection, union and join - all of which can be done with DDS - not to the
same extent as DDL but can still be done.

Paul

----- Original Message -----
From: "Alan Campin" <Alan.Campin@xxxxxxx>
To: <midrange-l@xxxxxxxxxxxx>
Sent: Monday, June 20, 2005 6:20 PM
Subject: RE: DBA Question


>> Did you know that a logical can select only certain fields from a
>> physical file?  And that you can update the database using such a
>> logical, thereby gaining what you term database independence?  You can
>> even have JOIN logicals on an iSeries, albeit with limitations that SQL
>> JOINs aren't subject to (mostly because SQL JOINs have the option of
>> building intermediate tables when necessary).

Joe, you might want to read what I wrote again. You will note that I was
referring to exactly the scenario you are describing. Using a logical file
as logical view, not just as just as a file system file. Field select,
joins, etc.

>> We've done this sort of thing for many years, but we are careful about
>> it, because updating only a partial record is VERY dangerous.  On
>> writes, you can at least see NULL values, but a partially updated record
>> can be a very bad thing.

Ok, huh. What do you mean by a partial record? Are you talking about an
update of single field? Why would that be dangerous? A write using partial
fields can be dangerous, although if the database is setup correctly, it
shouldn't be.

>> In any case, the idea of changing the underlying tables of a database
>> without having to change any programs is simply silly.  Some programs
>> will have to change or else the changes are meaningless.  In the DB2/400
>> world, we simply recompile the ones that don't use the new fields and
>> we're done; a simple added step that really doesn't bother anyone but
>> the SQL folks.

Ok, you have lost my again. I am not saying that every program does not have
to change. Maybe only one program would need to change.

Not sure what you mean by "We simply recompile the one's that don't use the
new field". Do you mean, going through and recompiling every program in the
system that uses the table? I won't call that simple. They changed one table
at my company recently and had to recompile 700 programs. Had one analyst
working on it for 5 weeks and that was with Turnover doing the work.

In most companies, they don't even try. They just create an extension table
and then when they have too many programs using the extension, they create
another extension and so on. In some packages, I see this getting real
interesting.

> In a file system, logical and physical views of the data are the same,
> that is you bring the whole file into every program. As far as the
program
> knows, theirs is the physical view of the data.

>> This is NOT a logical file on the iSeries... thus I question the rest of
>> the discussion.

My point is that on the AS/400 we use the database as a file system. How
many times have you seen a logical file used as something except to build an
index with the entire record brought in?

What does this statement have to do with logical files? I am talking about a
file system and the concept of a file system on, for example, a S/36.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.