pg.ddx.io  pgsql-sql@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Aaron Bono <postgresql@aranya.com>
To: Richard Broersma Jr <rabroersma@yahoo.com>
Cc: Michael Glaesemann <grzm@seespotcode.net>
Cc: General Postgresql List <pgsql-sql@postgresql.org>
Subject: Re: Alternative to Select in table check constraint
Date: Sat, 1 Jul 2006 15:36:51 -0500
Message-ID: <bf05e51c0607011336o52513602sc93ee49f524d192a@mail.gmail.com> (raw)
In-Reply-To: <20060701014108.79890.qmail@web31811.mail.mud.yahoo.com>
References: <4FA18A22-AFC2-4C6A-A487-57DAEF09F59F@seespotcode.net>
	<20060701014108.79890.qmail@web31811.mail.mud.yahoo.com>

This is more of an implementation option, but when I worry about what is
active/inactive I put start/end dates on the tables.  Then you don't need
active indicators.  You just look for the record where now() is >= start
date and now() <= end date or end date is null.  You can even
activate/deactivate a badge on a future date.  Of course, this complicates
the data integrity - you will need some kind of specialized trigger that
checks the data and makes sure there are no date overlaps to ensure you
don't have two badges active at the same time.  But is also gives you a
history of badges and their activities.

-Aaron

On 6/30/06, Richard Broersma Jr <rabroersma@yahoo.com> wrote:
>
> > >         CHECK   ( 1 = ALL (     SELECT COUNT(STATUS)
> > >                                 FROM BADGES
> > >                                 WHERE STATUS = 'A'
> > >                                 GROUP BY EMPNO))
> >
> >  From the PostgreSQL docs (http://www.postgresql.org/docs/8.1/
> > interactive/sql-createtable.html)
> >
> > CREATE UNIQUE INDEX one_a_badge_per_employee_idx
> > ON badges (empno)
> > WHERE status = 'A';
> > http://www.postgresql.org/docs/8.1/interactive/sql-createindex.html
> > http://www.postgresql.org/docs/8.1/interactive/indexes-partial.html
>
> Michael,
>
> Partial indexs seem to be "what the doctor ordered!"   And your suggest is
> right on, the idea of
> the constraint is to allow only one active badge status at a time.
>
> But now that I think about it, using the authors suggestion (if it
> actually worked), how would
> would it be possible to change the active status from one badge to
> another?
>
> Oh well, partial index are obvious the superior solution since the entire
> table doesn't not have
> to be scanned to determine if the new badge can be set to active.
>
> Once again thanks for the insight.
>
> Regards,
>
> Richard Broersma Jr.
>
>

view thread (11+ messages)  latest in thread

Message-ID: <bf05e51c0607011336o52513602sc93ee49f524d192a@mail.gmail.com>
Permalink:  ../bf05e51c0607011336o52513602sc93ee49f524d192a@mail.gmail.com/
Also on:    postgresql.org/message-id/bf05e51c0607011336o52513602sc93ee49f524d192a@mail.gmail.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-sql@postgresql.org
  Cc: postgresql@aranya.com, rabroersma@yahoo.com, grzm@seespotcode.net
  Subject: Re: Alternative to Select in table check constraint
  In-Reply-To: <bf05e51c0607011336o52513602sc93ee49f524d192a@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox