Re: [GUSDEV] An important schema question (to me, anyways)

[Josef J. <ju...@cs...>]

Deborah Pinney <pi...@pc...> writes:
>
> There is a case here at Cbil, where we need to have the constraint in
> place. In that case dots.naentry is used as a book-keeping tool to keep
> track of modifications of Genbank entries.

This should be the purpose of the *_DATE and *_REL_VER fields,
to keep track of the modification of genbank entries.
Why would you need anything else?

This unique constraint sounds like it was implemented for
idiosyncratic reasons by someone at CBIL.  I'll bet this field
will continue to completely serve your needs if the unique
constraint is removed.

That the source_id field is provided in many tables to give
users at their respective sites the ability to do local
bookkeeping is great.  Putting a unique constraint
on this field for a perceived local bookkeeping need
is just a stumbling block that adds a bit of difficulty
to the GUS community.


So, shall this unique constraint on source_id of
AAEntry/NAEntry be eliminated?  (We don't have to
decide today).

Thanks for the response; Josef



> I think at one time the
> constraint did not apply to dots.aaentry.source_id (I can't swear on
> that though). That may have changed for the sake of consistency.
>
> Josef Jurek wrote:
>
> >Well, if people do not feel that source_id requires
> >an unique constraint in tables AAEntry/NAEntry,
> >I propose that these constraints be removed.  I can
> >of course just remove them in our local gus installations,
> >though I would prefer that our local development
> >of tools be compatible with canonical GUS.
> >
>
>Another option would be to just include the fields:
>
>      CREATED_DATE                 DATE
>      CREATED_REL_VER              NUMBER(5)
>      SEQ_DATE                     DATE
>      SEQ_REL_VER                  NUMBER(5)
>      ANNOT_DATE                   DATE
>      ANNOT_REL_VER                NUMBER(5)
>
>into AASequenceImp/NASequenceImp and eliminate
[...]