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
16 matches
Mail list logo
