From: | Thomas Kellerer <spam_eater(at)gmx(dot)net> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Best practices for aggregate table design |
Date: | 2015-10-08 05:56:52 |
Message-ID: | mv50j3$1a8$1@ger.gmane.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
droberts schrieb am 06.10.2015 um 20:53:
> Okay, so is it safe to say I should use loosely use these guidelines when
> deciding whether to model an attribute as a dimension
> (type=[inbound,outbound]) vs. bundling with a measure (total_inbound) ?
>
> If you know the number of values for a dimension are fixed (e.g. boolean),
> then creating a measure will have benefits of:
> - reduced number of rows/storage
> - better performance since less indexing/vacuuming
>
> the drawbacks are:
> -rigid structure, not very extensible over time (e.g. later realize I need
> to also track 'internal' calls).
>
> In my case, I'm now needing to add another measure 'encrypted=true/false',
> so my table is starting to look like
Have you considered using a hstore column to store the attributes you don't know yet?
Which makes this extensible, flexible and fast.
From | Date | Subject | |
---|---|---|---|
Next Message | hari.fuchs | 2015-10-08 07:49:10 | Re: Best practices for aggregate table design |
Previous Message | Ramalingam, Sankarakumar | 2015-10-08 05:01:17 | Re: postgres standby won't start |