Message-ID: <534D5800.1060400@gmail.com>
Date: Tue, 15 Apr 2014 10:02:08 -0600
From: Rob Sargent <robjsargent@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: pgsql-general@postgresql.org
Subject: Re: Approach to Data Summary and Analysis
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>
In-Reply-To: 
 <CAAXGW-wOw1K__imSWt8WAwAa6Ed2EPOCR8LBBqsd1fpn_E5hvQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-general-owner@postgresql.org

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