Re: Duplicates Processing - Mailing list pgsql-sql

From Rob Sargent
Subject Re: Duplicates Processing
Date
Msg-id 4CAFADAD.7060600@gmail.com
Whole thread Raw
In response to Re: Duplicates Processing  (Gary Chambers <gwchamb@gmail.com>)
Responses Re: Duplicates Processing  (Gary Chambers <gwchamb@gmail.com>)
List pgsql-sql
My understanding was that the values were in fact in the data of the
"replacers".  If not, you are correct.  In this case the replacers are
more like alias for the only instance you have.

If the replacers are immutable by all means ship them off to some other
table (where I suppose the become pointers to other suppliers of the
type of thing holding the real data). Not sure I've ever met immutable
data but there you go ;)

And to your point of self-reference, it would be to a co-worker more
than a manager.  Managers are often not good replacements for workers. :)


On 10/08/2010 04:12 PM, Gary Chambers wrote:
> Rob,
> 
>> Yes.  With this you can find all part numbers/supplies which match your
>> value, wattage criteria in one table. Or exclude any which have a
>> non-null is_replacement_for value.
> 
> I understand -- thanks.  I have received contradictory advice in a
> purely data modeling context.  What about the null values that will be
> in the properties columns of the part?  It would appear to be more
> applicable to an employee database where the columns are populated
> regardless and the "replacement_for" in the context of our discussion
> would be a self-reference to the employee's manager.  No?
> 
> Thanks again for your help.
> 
> -- Gary Chambers


pgsql-sql by date:

Previous
From: Frank Bax
Date:
Subject: Re: counting related rows
Next
From: James Cloos
Date:
Subject: Re: counting related rows