Форум: "Базы";
Текущий архив: 2007.10.14;
Скачать: [xml.tar.bz2];
ВнизУдаление дубликатов из таблиц Найти похожие ветки
← →
ambhtr (2007-06-04 09:43) [0]Есть DBF таблица. Количество записей от 1.5 млн. до 3-4млн.
В таблицах периодически, по независящим от меня причинам (программа не моя), появляются дублирующие записи, от которых надо избавляться.
Посоветуйте, как это лучше сделать?
Проиндексировать, и затем, пошагово проходить и сравнивать предыдущую с последующей записями? Но вроде бы очень не рационально. Таких записей 3-4%.
Сейчас я их выбираю запросом. Но как сделать лучше? Перебирать результаты запроса, искать locate-ом и удалять все записи кроме первой?
Посоветуйте. Может есть уже отработанные алгоритмы?
← →
Sergey13 © (2007-06-04 09:51) [1]> [0] ambhtr (04.06.07 09:43)
> Сейчас я их выбираю запросом.
Ну так модифицируй запрос на удаление выбранного.
← →
ambhtr (2007-06-04 10:05) [2]Но как при этом сделать чтобы одна запись из выбранных дубликатов все-таки осталась?
← →
Johnmen © (2007-06-04 10:08) [3]Любым способом убрать дубликаты. Один раз.
Потом построить необходимый уникальный индекс. Дубликаты не будут появляться...
← →
Sergey13 © (2007-06-04 10:13) [4]> [2] ambhtr (04.06.07 10:05)
Модифицировать запрос соответствующим образом, что бы делал то что надо.
ЗЫ: Для 3-4 лимонов записей давно пора думать о нормальной СУБД. ИМХО.
← →
ambhtr (2007-06-04 10:22) [5]
> Sergey13 © (04.06.07 10:13) [4]
Согласен. Но это от меня не зависит.
А сейчас надо, извините за повтор, дубликаты убрать. Но одна запись из них должна же остаться.
Неужели от перебора не уйти?
← →
Sergey13 © (2007-06-04 10:24) [6]> [5] ambhtr (04.06.07 10:22)
> Неужели от перебора не уйти?
Ты можешь еще 1000 раз переспросить, но пока от тебя не будет конкретных условий задачи ответы будут только общего плана.
← →
ANB © (2007-06-04 10:27) [7]
> Потом построить необходимый уникальный индекс.
В дбф, к сожалению, уникальный индекс имеет другое назначение и не предупреждает появление дублей.
> Неужели от перебора не уйти?
Запости структуру таблицы, критерий понимания, что записи являются дублями и критерий - какую из оных оставить.
← →
sniknik © (2007-06-04 10:49) [8]> В дбф, к сожалению, уникальный индекс ...
смотря какой dbf, новый foxpro (который ODBC VFP и т.д.) имеет полноценные ключи.
то же самое по
> ЗЫ: Для 3-4 лимонов записей давно пора думать о нормальной СУБД. ИМХО.
если это фокс и программа написана на нем же... то это и есть нормальная субд.
если же старый, или dbase тоже старый (через что работает прога?) то на таких обьемах и только периодические глюки... да программисту надо памятник поставить, который это писал.
не лезь туда тогда, имхо, только хуже сделаешь. так время от времени продолжай дубли чистить, при отключенной основной. пока пишется заказанный аналог... заказал уже надеюсь?
а оптимальность алгоритма при такий периодических и редких чистках роли не играет. ну какая разница бедет ли это 10 мин, или пол часа раз в месяц?
← →
ambhtr (2007-06-04 11:00) [9]Все-таки выкладываю, на всякий случай -
Структура таблицы:
N_ID - number
barcode - character
OperType - number
Comment - character
запрос по выявлению дубликатов:
sTstSQL := "select T1.barcode, T1.OperType, T1.Comment, T1.N_ID"+
" from " + nmDBF + " T1," + nmDBF + " T2" +
" where t1.barcode = t2.barcode "+
" and T1.N_ID<>T2.N_ID "+
" and T1.OperType = T2.OperType "+
" group by T1.barcode, T1.OperType, T1.Comment, T1.N_ID";
Хотелось бы сделать, все-таки, красиво.
Впрочем...
← →
sniknik © (2007-06-04 11:16) [10]красиво, для файл сервера и таблицы с индексами это активировать нужные индексы и сделать 1 проход по таблице, запоминаешь значение проверяемых полей, переход next, сравниваешь (при активных индексах все одинаковые записи будут рядом), совпало значит дубль, удалить, нет снова запоминаешь значения. и т.д.
а запросы это только перегонять инфу туда сюда.
← →
Sergey13 © (2007-06-04 11:17) [11]> [9] ambhtr (04.06.07 11:00)
Можно попробовать так.delete from nmDBF T1
where T1.N_ID not in
(select min(T2.N_ID) from nmDBF T2
group_by t2.barcode,T2.OperType,T2.Comment)
Желательно экспериментировать НЕ на боевой таблице ессно. 8-)
← →
ambhtr (2007-06-04 11:23) [12]
> sniknik © (04.06.07 11:16) [10]
Спасибо. Это первое, что пришло в голову. Оно и остается как запасной вариант. Но пока, все-таки попробую совет от
> Sergey13 © (04.06.07 11:17) [11]
Буду благодарен и за другие рекомендации.
← →
Anatoly Podgoretsky © (2007-06-04 11:53) [13]
INSERT INTO T2 SELECT DISTINCT * FROM T1
← →
Sergey13 © (2007-06-04 11:55) [14]> [13] Anatoly Podgoretsky © (04.06.07 11:53)
Так у него ИД-шники вроде разные.
← →
Anatoly Podgoretsky © (2007-06-04 11:56) [15]Возможно обычный проход по отсортированой таблице будет самым оптимальным.
← →
Кирей (2007-06-07 15:07) [16]Ну а если записи идут подряд, а N_ID не равны, то из своего запроса грохни записи с четными(или нечетными) N_ID
← →
Sergey13 © (2007-06-07 15:19) [17]> [16] Кирей (07.06.07 15:07)
Хороший критерий. Можно еще каждого третьего расстре... тьфу, удалить. 8-)
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2007.10.14;
Скачать: [xml.tar.bz2];
Память: 0.49 MB
Время: 0.035 c