> -----Original Message-----
> From: David Schnepper
>
> Sent: Martes 4 de Abril de 2000 16:23
> My gut reaction:
> - Do not automatically create indices for FK's.

Seems more and more people go in that direction... it's very likely I will
lose my auto-generated indexes. ;-)

> - SysAdmin should be allowed to disable / delete any index (even
> those used
> for PK / FK relationships)

Yes, I want sysdba more as UNIX's root than as NT's administrator, namely,
more power to sysdba.

> - Ditto for triggers (even system triggers - yes, RDB$TRIGGER4
> should allow
> it!)
>
> Dave

I admire your enthusiasm. Paraphrasing you: where do you draw the line
between flexibility and risk of ignoring/bypassing all the consistency
checks?
For some "special tasks", maybe they could be reduced to extensions to
standard syntax or to commands in QLI... it seems better to have the engine
do a bunch of dangerous steps. For example, currently you cannot drop a
procedure that's referenced by another and there seems to be problems
altering it, too. One approach is to be able to do such things directly =>
ignoring the dependency. Other approach is to build some functionality so
all necessary steps are taken and you don't have much chance to let the db
in an inconsistent state if you forget one step. Not sure I made my thought
clear.

On other side of the indexes' story, I remember that while kinobi was in
closed beta testing, I requested the detection of duplicated indexes, so if
you happen to define an index whose characteristics are exactly the same
than those of a previously defined (either implicit or explicit) index, then
proposed answers can be:
- Give an error message.
- Fail silently => your index already exists. No more work needed.
- If the new CREATE INDEX command is creating the index in an ACTIVE state,
activate the existing index. Deactivate it if the new CREATE INDEX command
is creating an INACTIVE index.

Just my 1E-15 cents.

C.