Последовательная замена множества уникальных значений на другие без возникновения дубликатов

[mazzy]

Цитата:

Сообщение от gl00mie

Пример из жизни: замена определенным образом сгенерированных значений поля на значения, сгенерированные иным образом - при условии, что по этому полю существует уникальный индекс.

выключать уникальный индекс ни в какой момент нельзя?

[gl00mie]

Цитата:

Сообщение от mazzy

Заменить? Почему именно этот глагол?

Потому что он точнее всего отражает суть того, что мне нужно было сделать

Цитата:

Сообщение от mazzy

добавляешь новое промежуточное поле - результат функции.

Нужно было решить задачу на работающей системе; просто так менять схему данных в ней "по живому" нельзя. Кроме того, на поле в моем случае есть ссылки из других таблиц, их нужно было обновлять вместе со значением поля для сохранения консистентности данных.

Цитата:

Сообщение от mazzy

выключать уникальный индекс ни в какой момент нельзя?

Боже упаси! В базе ведь куча компаний, люди работают - еще нагенерят дубликатов, разгребай потом, а мне надо-то было только в паре компаний данные перебить. А караулить до ночи, когда таблица вроде как никому не нужна, очень уж не хотелось.

[mazzy]

Цитата:

Сообщение от gl00mie

Кроме того, на поле в моем случае есть ссылки из других таблиц, их нужно было обновлять вместе со значением поля для сохранения консистентности данных.

понятно.
тогда вместо update нужно использовать renamePrimaryKey.
главное - внутри транзакции значения могут быть и неуникальными.

Цитата:

Сообщение от gl00mie

А караулить до ночи, когда таблица вроде как никому не нужна, очень уж не хотелось.

Все равно на время апдейта таблица будет залочена

[gl00mie]

Цитата:

Сообщение от mazzy

тогда вместо update нужно использовать renamePrimaryKey.

С точки зрения Аксапты поле, значения которого я перебивал, не является первичным ключом, кроме того, оно вообще-то уникально лишь в рамках комбинации значений других полей (впрочем, как и любой первичный ключ в таблице, данные которой хранятся в разрезе компаний).

Цитата:

Сообщение от mazzy

главное - внутри транзакции значения могут быть и неуникальными.

При условии, что update_recordset уйдет на СУБД одним запросом.

Цитата:

Сообщение от mazzy

Все равно на время апдейта таблица будет залочена

Не таблица, а определенный набор записей - и то разве что в трешке, кроме того, при использовании моего способа можно обновлять данные множеством маленьких транзакций, получая после завершения каждой консистентный результат.

[mazzy]

Цитата:

Сообщение от gl00mie

кроме того, при использовании моего способа можно обновлять данные множеством маленьких транзакций, получая после завершения каждой консистентный результат.

разве что так.
но:
1. set для большого числа записей будет работать очень-очень-очень медленно, да еще и с квадратичным временем O(n^2).
2. все равно нужно будет делать в одной транзакции - ведь важно, чтобы при работе алгоритма не появлялись новые записи с кодами, о которых алгоритм не знает

может таки одна транзакция лучше?

[gl00mie]

Цитата:

Сообщение от mazzy

set для большого числа записей будет работать очень-очень-очень медленно, да еще и с квадратичным временем O(n^2).

С чего бы это? Я лично всегда был уверен, что Set'ы и Map'ы за счет сортировки используют бинарный поиск, и зависимость времени поиска - O(log2(n)+1).

[mazzy]

Цитата:

Сообщение от gl00mie

С чего бы это? Я лично всегда был уверен, что Set'ы и Map'ы за счет сортировки используют бинарный поиск, и зависимость времени поиска - O(log2(n)+1).

1. не уверен
2. внутри есть цикл, в котором вызывается difference. Даже если сам difference работает O(log2(n)+1), то вся конструкция будет O(n*(log2(n)+1)). А скорее O(n^2) из-за intersection.

Тут конечно считать нужно... Но intersection + difference внутри цикла сильно смущают. Особенно на больших множествах

еще раз спасибо за клевую задачу.