pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Vincent Veyron <vincent.veyron@libremen.org>
To: Robert DiFalco <robert.difalco@gmail.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Cc: pgsql-general@postgresql.org <pgsql-general@postgresql.org>
Subject: Re: Approach to Data Summary and Analysis
Date: Mon, 14 Apr 2014 23:35:53 +0200
Message-ID: <20140414233553.626524a7bb8718a451499a7f@libremen.org> (raw)
In-Reply-To: <CAAXGW-zzACjHfREYEo4FBmJXLHD7d=nMH-i4WeSi_DTWBLzezQ@mail.gmail.com>
References: <CAAXGW-zzACjHfREYEo4FBmJXLHD7d=nMH-i4WeSi_DTWBLzezQ@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-general>

On Mon, 14 Apr 2014 09:27:29 -0700
Robert DiFalco <robert.difalco@gmail.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


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general



view thread (12+ messages)  latest in thread

Message-ID: <20140414233553.626524a7bb8718a451499a7f@libremen.org>
Permalink:  ../20140414233553.626524a7bb8718a451499a7f@libremen.org/
Also on:    postgresql.org/message-id/20140414233553.626524a7bb8718a451499a7f@libremen.org

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: vincent.veyron@libremen.org, robert.difalco@gmail.com, pgsql-general@postgresql.org
  Subject: Re: Approach to Data Summary and Analysis
  In-Reply-To: <20140414233553.626524a7bb8718a451499a7f@libremen.org>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox