X-Original-To: pgsql-sql-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id A61E39FA667 for ; Sun, 2 Jul 2006 22:52:35 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 98950-04 for ; Sun, 2 Jul 2006 22:52:27 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey- Received: from web31812.mail.mud.yahoo.com (web31812.mail.mud.yahoo.com [68.142.207.75]) by postgresql.org (Postfix) with SMTP id DE42B9FA60C for ; Sun, 2 Jul 2006 22:52:27 -0300 (ADT) Received: (qmail 30513 invoked by uid 60001); 3 Jul 2006 01:52:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=TP6aKEnkgCyWf402Kt6fScfUo1CjAoixnyoV01Ku4drR93f1puQYWh24BkzvSO5/elK1vU4O/5ew6YXtwFuETFfbuYiq3cZ0ApMzcS8a65IrMx0RnI+diKPrqutSW7hOHRkPR/QYtX7smSsXMqchujVlwUeerH0eVXHDuBgqfA0= ; Message-ID: <20060703015226.30511.qmail@web31812.mail.mud.yahoo.com> Received: from [24.54.196.198] by web31812.mail.mud.yahoo.com via HTTP; Sun, 02 Jul 2006 18:52:26 PDT Date: Sun, 2 Jul 2006 18:52:26 -0700 (PDT) From: Richard Broersma Jr Subject: Re: Alternative to Select in table check constraint To: Aaron Bono Cc: Michael Glaesemann , General Postgresql List In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200607/14 X-Sequence-Number: 25588 > 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. Good point. I take it that this type of solution stems from temporal schema design. Regards, Richard Broersma Jr.