Re: Variable constants ?

Поиск
Список
Период
Сортировка
От Charles Clavadetscher
Тема Re: Variable constants ?
Дата
Msg-id 11025034d9e2c2b5e0316aa1f80dfe68@swisspug.org
обсуждение исходный текст
Ответ на Re: Variable constants ?  (Rich Shepard <rshepard@appl-ecosys.com>)
Ответы Re: Variable constants ?  (Rich Shepard <rshepard@appl-ecosys.com>)
Список 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





В списке pgsql-general по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Error XX000 After pg11 upgrade
Следующее
От: Peter Grman
Дата:
Сообщение: Bad Estimate for complex query with JOINS on subselects and OR in where conditions