Re: Approach to Data Summary and Analysis

From: Vincent Veyron <vincent(dot)veyron(at)libremen(dot)org>
To: Robert DiFalco <robert(dot)difalco(at)gmail(dot)com>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Approach to Data Summary and Analysis
Date: 2014-04-14 21:35:53
Message-ID: 20140414233553.626524a7bb8718a451499a7f@libremen.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-performance

On Mon, 14 Apr 2014 09:27:29 -0700
Robert DiFalco <robert(dot)difalco(at)gmail(dot)com> wrote:

> I have several related tables that represent a call state.
>
> And so on for calls_connected, calls_completed, call_errors, etc.
>
> So for my question -- is the choice between these a personal preference
> sort of thing or is there a right or wrong approach? Am I missing another
> approach that would be better?

Hi Robert,

I guess a call state is subject to change, in which case you would have to shuffle records between tables when that happens?

ISTM you should consider using only a 'calls' table, and add an 'id_call_state' field to it that references the list of possible states. This would make your queries simpler.

create table call_state(
id_call_state text PRIMARY KEY,
libelle text);

INSERT INTO call_state (id_call_state, libelle) VALUES ('calls_connected', 'Connected'), ('calls_completed', 'Completed'), ('call_errors', 'Error');

> CREATE TABLE calls (
> id BIGINT NOT NULL, // sequence generator

id_call_state INTEGER NOT NULL REFERENCES call_state,

> user_id BIGINT NOT NULL,
> called TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,
>
> PRIMARY KEY (id),
> FOREIGN KEY (user_id) REFERENCES my_users(id) ON DELETE CASCADE
> );

--
Regards, Vincent Veyron

http://libremen.com/
Legal case, contract and insurance claim management software

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Vincent Veyron 2014-04-14 21:43:09 Re: Approach to Data Summary and Analysis
Previous Message David G Johnston 2014-04-14 19:55:26 Re: Querying all documents for a company and its projects etc

Browse pgsql-performance by date

  From Date Subject
Next Message Nick Eubank 2014-04-14 21:46:04 Tuning Postgres for Single connection use
Previous Message Ryan Johnson 2014-04-14 20:30:56 Re: SSI slows down over time