| From: | Richard Broersma Jr <rabroersma(at)yahoo(dot)com> |
|---|---|
| To: | Aaron Bono <postgresql(at)aranya(dot)com> |
| Cc: | Michael Glaesemann <grzm(at)seespotcode(dot)net>, General Postgresql List <pgsql-sql(at)postgresql(dot)org> |
| Subject: | Re: Alternative to Select in table check constraint |
| Date: | 2006-07-03 01:52:26 |
| Message-ID: | 20060703015226.30511.qmail@web31812.mail.mud.yahoo.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-sql |
> 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Phillip Smith | 2006-07-03 02:16:04 | Re: join two tables with sharing some columns between two |
| Previous Message | Richard Broersma Jr | 2006-07-03 01:50:25 | Re: Alternative to Select in table check constraint |