NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/database/ingres/2233

Text File | 1993-01-12 | 3.4 KB | 67 lines

Newsgroups: comp.databases.ingres
Path: sparky!uunet!usc!zaphod.mps.ohio-state.edu!darwin.sura.net!sgiblab!rtech!ingres!billc
From: [e-mail] (Bill Coffin)
Subject: Re: DB admin tools
Message-ID: <[e-mail]>
Reply-To: [e-mail]
Organization: Ingres, An ASK Company, Alameda CA
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: 12 Jan 93 22:14:29 GMT
Lines: 55

In article <[e-mail]>, [e-mail] (Mark Jaeger) writes:
>
>Maybe we're just quibbling about apples and oranges, but I thought that
>"system catalog" meant anything that is in an empty, newly-created
>database.  At least, that's what it meant in version 5.  I think it
>might be more correct to say that "iidbdepends" is not part of the
>Standard Catalog Interface, but rather it is an internal dbms system
>catalog, for INGRES internal use only.

Right.  There is an arcane terminology here.  My understanding is
that the "System Catalogs" are documented, in 6.4, in an appendix of
the SQL Reference Manual.  Our guarantee is that these catalogs will
never disappear, that no column will ever change or disappear.  We
reserve the right to add new columns, or to increase the length of a
character column.  So don't ever fetch into a struct, fetch into
individual variables (which can be struct members) explicitly.
iidbdepends is not documented in the SQL Reference Manual, so our
guarantees do not apply to it.  However, it is completely safe to
rely on, say, iitables, as long as you program with a little
caution.

>> My reccomendation to Rob McNicholas, the original poster, would be to
>> use views liberally while developing the applications.  You can use
>> many tricks to avoid the necessity of redefining tables.
>
>Bill's suggestion doesn't speak to most of the reasons that I need to
>drop and recreate a table: adding a column; making a column longer; and
>renaming a column.  That we do this so frequently is probably due to a
>flawed development process, with an inadequate analysis and design
>phase, but the fact remains that we users _do_ have to change our tables
>from time to time.  The copydb tool has long been inadequate to the
>task, really since version 6, when INGRES first started dropping views
>when you drop a table.

I don't mean to offer an excuse.  I certainly believe we should do
better at supporting table changes.  And there are many requirements
that cannot be handled by "tricks".  However, in a development
environment a trick can sometimes save you a lot of trouble.  Yes,
ALTER TABLE would be better, but I have seen instances where a
column can be added by creating a view and joining to a second table.
Slower, but it's a development environment.  COPYDB of all of the user's
objects will recreate dependencies, so you can COPYDB, edit the copy
script, and reload.

Also, I think in general that it's a good policy to implement a
schema so that applications access it entirely through views.  This
makes it easier to change the schema by twiddling the views.
(Although this gets problematic, for example when your updates fail
because an altered view becomes non-updateable.)  When you "go
production", you switch to real tables.

--
Bill Coffin, at Ingres, An ASK Company, Alameda CA
[e-mail]    510.748.3387
<standard_disclaimer> <gratuitous_witticism> <obscure_quote> <annoying_graphic>