Ситуация такая.

Есть справочник Номенклатура, пустой.

Грузим в нее мегатаблицу (предположим, на миллион позиций).

Код- автоматом, заполняем артикул.

Когда грузим очередной элемент, делаем запрос к справочнику, а есть ли уже с таким артикулом ? Если есть, пропускаем, не создаем новый.

Пока элементов немного, будет быстро (Запрос проверки существования таких же артикулов).

А когда сотни тысяч, теоретически, сильно тормозить будет запрос ?

Быстрее ли будет опрашивать запросом регистр сведений, и туда писать загруженные артикулы ?

Быстрее ли будет опрашивать запросом регистр сведений, и туда писать загруженные артикулы ?

Монопенисуально.

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

зы
100 тыс позиций, 5 левых запросов, четыре вложенных запроса, 10 параметров, одна иерархия
убивают 8.2 на месте

Быстрее будет кэшировать результаты запроса. И сначала искать в кэши, а потом уже запрос к БД и добавления в кэш

Афтор спрашивает про поиск.

а что, артикулы есть не у каждой позиции ?

(6) У каждой. Надо проверять на совпадение. Это я для примера задачу до минимума упростил, чтобы проще было комментировать. В целом, понятно.

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

Откуда грузим? Может сначала уникальный индекс построить и не проверять каждый раз...

http://edu.nstu.ru/courses/saod/file_structure.htm

Оценка сложности по B дереву
O(logt n)

где n - число данных, тоесть количество строк таблицы, t - число ключей в узле дерева.

Тоесть, при линейном увеличении N
время поиска будет возрастать согласно
Logt(N)

t - тоже будет увеличиваться по мере роста числа записей, но далеко не линейно.

t - будет зависеть от самих данных, для которых строиться индекс.

Берем Ексель, строим динамику.

Правда в SQL B+ дерево используется для формирования индексов, но для него формулу не нашел, но вряд ли другая.

(9) на самом деле, для 1 линейного списка понятно, в принципе мне ответили, способ придумаю, основная задача не (0), (0) для примера.

(10) Спасибо. Сейчас на практике прикину, обработкой создам элементы+ секундомер подключу.

(10) о, юность вспомнил, в универе это разбирали, писали такие деревья с хэш-функциями на с++

Я тож считаю, что будет конечно дольше, но если индексы сделать, то совсем некритично дольше

(10) если найти значение то скорость не будет зависить от размера таблицы и в среднем буде 1-3 обращения
и вообще тут не озвучили скл какой