Сколько будет идти запись 2 000 0000 единиц различных НСИ в справочники? 1с 8.3

Нормально так будет идти

(1) На первом пентиуме? Ну не знаю

(0) ровно 876487548145 миллисекунд

Если будешь использовать Джамп, то быстро)

Как можно увеличить скорость записи?

(5) 1.Монопольный режим !

(5) вручную управлять транзакцией пачками по ХХХХ шт.

(5) Писать по 1000 шт. в транзакции + ОбменДанными.Загрузка = Истина

Ну, где то 250 эл. / сек.
Часа за 2.5 запишется.

(0) Целевое время какое?

(11) >>А зачем использовать транзакции?

Чтобы уменьшить их количество.
С уважением, КЭП

9, это в транзакции по 1000 элементов - 250 эл. / сек?

(14) ну 1000 штук не накладывает. и 10000 не накладывает. Вот 100000, это может наложить.

(14) забаньте уже этого недотролля по ип.

(17) в транзакции быстрее пишется. причем в 100 и более раз.

(17) чтобы меньше раз происходила запись в БД.
что будет быстрее, носить из багажника 100 бутылок пива по одной или 5 раз относить ящики по 20 бутылок?

(21) тут баланс нужен.

(20) В BOL например, устроит?

(20) например 10 элементов к примеру. У вас 10 транзакций, я меня одна транзакция. временем записи самого элемента элемента можно пренебречь, оно равно нулю. Поэтому если вы пишете без транзакций, у вас запись будет в 10 раз долльше чем у меня. Потому что у меня одна транзакция. Ферштеен?

(21) Не то процитировал.

"необходимо искать компромисс между скоростью и параллельностью работы пользователей, и целостностью данных"

(21) 20 миллионов транзакций всё равно хуже. Тут надо искать оптимальное количество. Составили биквадратное уравнение и путем решения этого уравнения выяснили, что оптимально делать порциями, где-то по 1000 элементов в каждой порции

(26) (27) + 100500

можно, конечно, за раз 100 бутылок утащить. Но, пупок развяжется

(5) Самое быстрое - писать средствами SQL прямо в таблицу

(31) отмазки пошли

еще привилегированный режим нужно не забыть включить

(29) ну теоретически да, вы правы, но если на практике (0) запустит по вашей системе, он будет ждать несколько месяцев. И потом будет сидеть удивляться. Как же так, всё правильно сделал вроде? И будет ругать Нуралиева.

(29) На память не помню, но если поискать, 100% найдется. Но достаточно и здравого смысла. А если его мало, проведи тесты.

Ты же не будешь отрицать, что транзакция имеет накладные расходы (зависящие, среди прочего, от СУБД).

(31) А что важнее - чтобы был пруф или чтоб быстрее загрузилось? :)

(37) за счет накладных расходов. он жа написал.

(37) Часть накладных расходов постоянна, т.е. не зависит от количества элементов в транзакции. Еще часть зависит, но нелинейно, а убывает с ростом количества элементов. Вот за счет них и выигрыш.

P.S. 1000 это не "большая" транзакция. Большая это 100000. Там уже другая часть, нелинейно растущая, начинает превалировать.

(41) Как это не знаем. Берем профайлер и узнаем.