hVosttПростое, это процедура, как предложил Алексей К.

Эффективное? Нет. Ни разу, я вас умоляю. Это ещё надо доказать.

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

Petro123Алексей КПоэтому лично я скептически отношусь к решающему превосходству булкинсерта. Проще сгенерировать SQL-пакет.ну это уже не импорт файла.
Ты пробовал файл 800мегов так вставлять?В чём проблема-то? Никто не заставляет всё пихать в один пакет. Размер пакета определить опытным путём.
Petro123Алексей К,
И с один ко многм как быть?
Заказы -> детализация
?В хранимой процедуре можно организовать любую логику. И не такое вставляли...

hVosttАлексей КЭто ещё надо доказать.

Если, как я сказал, данные залить в отдельно выделенную таблицу, а потом оттуда импортировать данные, то

1. Можно на полном наборе данных выявлять нарушения, грузить только то, что нужно, детектить дубли, джойнить, отсекать, преобразовывать.
2. Исходную таблицу можно проапдейтить с результатами подготовки к загрузке (п.1), статусами, причинами и проч.
3. Можно избежать длительной блокировки и жирной транзакции (после выполнения проверки в п.1), заливать данные порциями или построчно, при чём это может работать надёжно, полностью асинхронно и любой может видеть текущий прогресс в любой момент из любого клиента и контролировать.
4. Источником данных является таблица, а непонятно откуда и как залетающие данные, которые могут отвалиться по непонятным причинам, что для СУБД является самым лучшим решением.
5. На таком принципе можно логику импорта вынести из СУБД и описывать где угодно в каких угодно нотациях и правилах. Но никто не мешает использовать процедуры и проч.

Это быстро, эффективно, сопровождаемо, расширяемо, не имеет различных костылей, прокладок и хаков.Признаюсь, я не знаю как это комментировать. Мне надо подумать... Ты уж прости...