Re: Duplicates Processing

From: Rob Sargent <robjsargent(at)gmail(dot)com>
To: Gary Chambers <gwchamb(at)gmail(dot)com>
Cc: pgsql-sql(at)postgresql(dot)org
Subject: Re: Duplicates Processing
Date: 2010-10-08 23:47:57
Message-ID: 4CAFADAD.7060600@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message James Cloos 2010-10-09 07:49:12 Re: counting related rows
Previous Message Frank Bax 2010-10-08 23:09:56 Re: counting related rows