Should history inherit employees and not other way around in readme?
mlt opened this issue · 4 comments
It seems to me that PK constraint should apply to current actual relation and not its (combined) history where that PK is violated. I mean shall history table inherit employees in the readme?
Thank you. Fixed.
I'm still confused about semantics. The way it is right now, one gets all records including historic ones from employees table whereas historic table contains old records only. This way, there is no table containing solely "currently valid/active" records.
I might miss the point, but it seems to me that employees should always contain valid entries only whereas employees_history, if inherited from employees, would contain all possible records, i.e., past and present.
Could you clarify why the inheritance is set the way it is?
That is how inheritance in PostgreSQL works. It may seem a little unintuitive, but if A inherits from B, SELECTs from B return everything from B and A whereas SELECTs from A return the content of A only.
In fact, it makes sense when you think about how it should work. Consider two tables FRUIT and APPLES. You want APPLES to inherit from FRUIT, but SELECTs from APPLES must return only apples whereas SELECTs from FRUIT must return apples as well as any other fruit.
duh..silly me. I haven't used PG inheritance in a while 😇