Best practices for aggregate table design

From: droberts <david(dot)roberts(at)riverbed(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Best practices for aggregate table design
Date: 2015-10-06 15:59:59
Message-ID: 1444147199298-5868940.post@n5.nabble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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 4 147 15 162
2015-01 null null 201 17 218

-----------------------

and a dimension table to easily convert city, state into their string
versions and also provide other attributes (e.g. GPS coordinates).

My questions are:
1. I'm including 'total_calls' in the schema even thought it could easily be
calculated from inbound + outbound. I did this for simplicity in a REST
call, is that a bad idea?
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?

Thanks!

--
View this message in context: http://postgresql.nabble.com/Best-practices-for-aggregate-table-design-tp5868940.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.

Responses

Browse pgsql-general by date

  From Date Subject
Next Message David G. Johnston 2015-10-06 16:26:12 Re: Best practices for aggregate table design
Previous Message Alvaro Herrera 2015-10-06 15:51:23 Re: [pgsql-es-ayuda] No funciona WITH con mas de 2 sentencias DML