Re: Duplicates Processing

Поиск
Список
Период
Сортировка
От Rob Sargent
Тема Re: Duplicates Processing
Дата
Msg-id 4CAF79EB.1080606@gmail.com
обсуждение исходный текст
Ответ на Re: Duplicates Processing  (Gary Chambers <gwchamb@gmail.com>)
Ответы Re: Duplicates Processing  (Gary Chambers <gwchamb@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Gary Chambers
Дата:
Сообщение: Re: Duplicates Processing
Следующее
От: Gary Chambers
Дата:
Сообщение: Re: Duplicates Processing