On Thu, Aug 15, 2019 at 11:27 PM Rich Shepard <rshepard@appl-ecosys.com> wrote:
> create table labor_rate_mult (
> rate real primary_key,
> start_date date not null,
> end_date date
> )
I think the rate should not be the primary key, since that would
prevent keeping the whole history when the value is resetted to a
previous one. Probably here a surrogate key will make the trick.
The range solution is probably a more elegant one.
I would also propose the over-complicated possibility of making an
extension wrapping functions that return each single constant value.
In this way, changing the value means upgrading the extension and is
another way to keep history of changes, but probably is because I
don't like one-raw tables so much.
Luca