Re: Best practices for aggregate table design
От | Thomas Kellerer |
---|---|
Тема | Re: Best practices for aggregate table design |
Дата | |
Msg-id | mv50j3$1a8$1@ger.gmane.org обсуждение исходный текст |
Ответ на | Re: Best practices for aggregate table design (droberts <david.roberts@riverbed.com>) |
Ответы |
Re: Best practices for aggregate table design
|
Список | 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.
В списке pgsql-general по дате отправления: