Re: Duplicates Processing - Mailing list pgsql-sql

From Rob Sargent
Subject Re: Duplicates Processing
Date
Msg-id 4CAF79EB.1080606@gmail.com
Whole thread Raw
In response to Re: Duplicates Processing  (Gary Chambers <gwchamb@gmail.com>)
Responses Re: Duplicates Processing
List pgsql-sql
On 10/08/2010 01:42 PM, Gary Chambers wrote:
> Tim,
> 
> Thanks for taking the time to reply!
> 
>> | INSERT INTO substitutes ([...])
>> |   SELECT [...] FROM
>> |     (SELECT *,
>> |             ROW_NUMBER() OVER (PARTITION BY wattage, tolerance, temperature
>> |                         ORDER BY part_number) AS RN
>> |      FROM parts) AS SubQuery
>> |   WHERE RN > 1;
> 
>> | DELETE FROM parts
>> | WHERE primary_key IN
>> |   (SELECT primary_key FROM
>> |     (SELECT *,
>> |             ROW_NUMBER() OVER (PARTITION BY wattage, tolerance, temperature
>> |                                ORDER BY part_number) AS RN
>> |      FROM parts) AS SubQuery
>> |    WHERE RN > 1);
> 
> You have solved the problem precisely as I described it.  In my haste
> to make the request for assistance, I omitted one critical piece of
> information that may call into question my data model.  In its current
> state, my substitute parts table contains only the part number (the
> "new" one, so-to-speak), a foreign key reference to the original parts
> table, and some location data (which is also in the original parts
> table).  Is there any advice you can offer in light of what I have
> just described? I apologize for the oversight.
> 
> -- Gary Chambers
> 

Perhaps a trade off between nullable fields and redundant types.  If
your original table simply had a nullable column called
isReplacementFor, into which you place in the subsequent rows the id of
the first instance found.


pgsql-sql by date:

Previous
From: Gary Chambers
Date:
Subject: Re: Duplicates Processing
Next
From: Gary Chambers
Date:
Subject: Re: Duplicates Processing