From: | Charles Clavadetscher <clavadetscher(at)swisspug(dot)org> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Variable constants ? |
Date: | 2019-08-16 04:41:43 |
Message-ID: | 11025034d9e2c2b5e0316aa1f80dfe68@swisspug.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 2019-08-15 23:27, Rich Shepard wrote:
> On Thu, 15 Aug 2019, stan wrote:
>
>> I need to put a few bossiness constants, such as a labor rate
>> multiplier
>> in an application. I am adverse to hard coding these things. The best
>> plan
>> i have come up with so far is to store them in a table, which would
>> have
>> only 1 row, and a column for each needed constant.
>>
>> Anyone have a better way to do this?
>>
>> Failing a better way is there some way I can limit this table to only
>> allow one row to exist?
>
> Stan,
>
> I've resolved similar issues with changing regulatory agency staff. For
> your
> application(s) I suggest a table like this:
>
> create table labor_rate_mult (
> rate real primary_key,
> start_date date not null,
> end_date date
> )
>
> This provides both a history of labor rate multipliers and the ability
> to
> select either the most current one or a previous one.
>
> If other factors affect the rate, add attribute columns for them.
>
> Regards,
>
> Rich
Another way to keep a history is using a daterange instead of two
columns for start and end date. Something like
create table labor_rate_mult (
rate real primary_key,
validity daterange not null
)
This makes it easier to manage and avoid e.g. overlappings.
Regards
Charles
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Grman | 2019-08-16 11:39:09 | Bad Estimate for complex query with JOINS on subselects and OR in where conditions |
Previous Message | Tom Lane | 2019-08-16 00:28:06 | Re: Error XX000 After pg11 upgrade |