From: Rob Sargent <robjsargent@gmail.com>
To: pgsql-general@postgresql.org
Subject: Re: Approach to Data Summary and Analysis
Date: Tue, 15 Apr 2014 10:02:08 -0600
Message-ID: <534D5800.1060400@gmail.com> (raw)
In-Reply-To: <CAAXGW-wOw1K__imSWt8WAwAa6Ed2EPOCR8LBBqsd1fpn_E5hvQ@mail.gmail.com>
References: <CAAXGW-zzACjHfREYEo4FBmJXLHD7d=nMH-i4WeSi_DTWBLzezQ@mail.gmail.com>
<CADfwSsAabdU0ix3e08daxACy8=gv1t=KGjHHgQGm6+A6Vq6ngg@mail.gmail.com>
<CADfwSsD1w-p3SH=woCPrcbrzkJ0mzJmSzfT61JSCaTk9y-jL0w@mail.gmail.com>
<CAAXGW-wOw1K__imSWt8WAwAa6Ed2EPOCR8LBBqsd1fpn_E5hvQ@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-general>
On 04/15/2014 09:53 AM, Robert DiFalco wrote:
> Actually that was exactly the initial table design. There were more
> fields because for my use case there were a lot more states and
> certain states have additional data (for example when a call goes from
> answered to connected it also gets the user_id of the person being
> connected to). So that one table started getting a LOT of columns
> which starting making it hard to reason about.
>
> The more normalized version has a couple of things going for it.
> COUNT, MIN, MAX, etc are very fast because I don't have to
> conditionally add null checks. Everything is inserted so for the
> millions of calls that get made the normalized schema was much more
> efficient for writing. It was also easier to understand. The answer
> table only has calls that were answered, the error table only has
> calls the resulted in an error after being connected, etc.
>
> I know this kind of gets into a religious area when discussing NULLs
> and what level of normalization is appropriate so I don't want to
> spark any of that on this thread. But only doing inserts and never
> doing updates or deletes performed very well for large data sets.
>
> That said, I could explore a compromise between the monolithic table
> approach and the completely normalized set of tables approach. Thanks
> for your input!
>
I wonder if the "LOT of columns" are the bits that need to be parcelled
off as specific to one condition of a call?
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
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: robjsargent@gmail.com, pgsql-general@postgresql.org
Subject: Re: Approach to Data Summary and Analysis
In-Reply-To: <534D5800.1060400@gmail.com>
* 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