[GENERAL] Approach to extract top records from table based upon aggregate

2015-11-02 Thread droberts
Hi, I have a table that contains call records. I'm looking to get only records for users who made the most calls over a particular time duration in an efficient way. calls() time, duration, caller_number, dialed_number -- query to get top 10 callers select caller_number, count(1) from

Re: [GENERAL] ID column naming convention

2015-10-13 Thread droberts
Gavin Flower-2 wrote > On 14/10/15 06:36, droberts wrote: >> Hi, is there a problem calling ID's different when used as a FK vs table >> ID? >> For example >> >> >> mydimtable () >> ID >> name >> description >> >&

[GENERAL] ID column naming convention

2015-10-13 Thread droberts
Hi, is there a problem calling ID's different when used as a FK vs table ID? For example mydimtable () ID name description myfacttable () my_dim_id # FK to ID above total_sales I 'think' if I don't enforce foreign key constraints, then this practice prevents tools from being able to

Re: [GENERAL] Best practices for aggregate table design

2015-10-09 Thread droberts
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 >

Re: [GENERAL] Best practices for aggregate table design

2015-10-08 Thread droberts
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

Re: [GENERAL] Best practices for aggregate table design

2015-10-07 Thread droberts
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.

Re: [GENERAL] Best practices for aggregate table design

2015-10-06 Thread droberts
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

Re: [GENERAL] Best practices for aggregate table design

2015-10-06 Thread droberts
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

[GENERAL] Best practices for aggregate table design

2015-10-06 Thread droberts
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