On 10/9/2015 6:07 PM, Roxanne Reid-Bennett wrote:
On 10/9/2015 3:16 PM, droberts wrote:
Thanks for everyone's help. Can anyone recommend a good book on
database modeling, around these 'cube' or aggregate concepts in
particular? I'm using Postgres but shouldn't matter too much I assume.
Given
On 10/9/2015 3:16 PM, droberts wrote:
Thanks for everyone's help. Can anyone recommend a good book on
database modeling, around these 'cube' or aggregate concepts in
particular? I'm using Postgres but shouldn't matter too much I assume.
Given the shift towards NoSQL for BI, and the age of the
David G Johnston wrote
> Nabble has a "quote" feature - please use it.
>
> On Thu, Oct 8, 2015 at 5:00 PM, droberts <
> david.roberts@
> > wrote:
>
>> I haven't but wouldn't it be better to wait and just add new columns
>> if/when
>> I need to?
>>
>
> Its worth keeping in the back of your min
Nabble has a "quote" feature - please use it.
On Thu, Oct 8, 2015 at 5:00 PM, droberts wrote:
> I haven't but wouldn't it be better to wait and just add new columns
> if/when
> I need to?
>
Its worth keeping in the back of your mind but I tend to think that
choosing hstore in order to "be flex
I haven't but wouldn't it be better to wait and just add new columns if/when
I need to?
--
View this message in context:
http://postgresql.nabble.com/Best-practices-for-aggregate-table-design-tp5868940p5869372.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
--
Se
On Thu, Oct 8, 2015 at 3:49 AM, wrote:
> Is there an advantage of hstore vs. json/jsonb?
>
Definitely over json because that is not indexable. I'm not seeing an
advantage over jsonb unless you want to prevent storing complex data
structures.
Thomas Kellerer writes:
> 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 th
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 dimensio
I see the advantage is for the developer. We right one REST API call that
leverages this single table regardless whether he wants groups by city for a
month or total for a month. Creating a separate table would make the
backend a bit more complex is all and wouldn't save on space I don't think.
>2. I'm adding a 'null' row to show all the calls for a given month
>regardless of city or state, again to simplify the client side. It adds a
>row and is somewhat sparse but preferrable by the developer. Acceptable
>practice?
do you see any advantage with this model?
I would store your monthly d
On Tue, Oct 6, 2015 at 2:53 PM, droberts wrote:
>
> month | city_id | state_id | total_calls_inbound | total_calls_outbound |
> total_calls_inbound_encr | total_calls_outbound_encr |
>
> getting a bit hairy but the alternative seems like it would start growing
> too quickly in rows and more I/O f
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
On Tue, Oct 6, 2015 at 2:34 PM, John R Pierce wrote:
> On 10/6/2015 11:24 AM, droberts wrote:
>
>> OR a dimension 'type' with values outbound/inbound and a single measure
>> column 'total' ?
>>
>
> that smells a bit too much like an "EAV" (entity-attribute-value) which is
> considered an antipatt
On 10/6/2015 11:24 AM, droberts wrote:
OR a dimension 'type' with values outbound/inbound and a single measure
column 'total' ?
that smells a bit too much like an "EAV" (entity-attribute-value) which
is considered an antipattern in relational circles
--
john r pierce, recycling bits in santa
Thanks for your response. One more follow-up question.
Is there a best practice when to create a measure that includes a
property/dimension?
Let me give an example, say in my example where I have outbound and inbound
calls.
Is is best to have measures:
-total_inbound
-total_outbound
OR
On Tue, Oct 6, 2015 at 11:59 AM, droberts
wrote:
> Hi,
> I'm trying to construct an agg table to capture phone call data and group
> by
> state, city and time but also want just general measures by month. I'm
> thinking to have this:
>
> month | city_id | state_id | total_calls_inbound | total_ca
Hi,
I'm trying to construct an agg table to capture phone call data and group by
state, city and time but also want just general measures by month. I'm
thinking to have this:
month | city_id | state_id | total_calls_inbound | total_calls_outbound |
total_calls
2015-01 12 2 54 2 56
2015-01 10
17 matches
Mail list logo
