B>Не понятно зачем столько таблиц.
B>Есть таблица Товары. Нужно дополнительно создать постоянную таблицу импорта товаров (в последующем можно будет посмотреть историю импорта, либо после импорта удалять).
B>К импортированным товарам джойните существующие товары. Отображаете получившийся датасет одной таблицей ...

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

B>... пользователь выставляет нужные флажки, жмёт Ок. Далее вы пробегаете по итоговому датасету и решаете что нужно делать с текущей записью.

В данном случае программа не должна ничего решать.
Если пользователь выставил флажок, он явно дал понять программе, что оба товара соответствуют друг другу и импортируемый товар надо загрузить, перезаписав сведения у существующего товара.

B> Либо скопом делаете инсерт/апдейт.

Да, это можно сделать для тех узлов дерева, у которых стоят соответствующие флажки.


Остался вопрос только в грамотном разделении всего этого кода на слои, классы и т.д.
Вот например, сгруппированные данные для отображения в виде дерева — это слой представления? Или это слой бизнес-логики?
По теории — дерево — это представление.
Однако, связь между импортируемым товаром и существующим товаром хранится в БД, эту связь пользователь фиксирует флажком.
Следовательно, связь (то есть узел дерева) — это объект бизнес-логики.
Как сделать лучше?

B>Не понятно зачем столько таблиц.
B>Есть таблица Товары. Нужно дополнительно создать постоянную таблицу импорта товаров (в последующем можно будет посмотреть историю импорта, либо после импорта удалять).
B>К импортированным товарам джойните существующие товары. Отображаете получившийся датасет одной таблицей ...

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

B>... пользователь выставляет нужные флажки, жмёт Ок. Далее вы пробегаете по итоговому датасету и решаете что нужно делать с текущей записью.

В данном случае программа не должна ничего решать.
Если пользователь выставил флажок, он явно дал понять программе, что оба товара соответствуют друг другу и импортируемый товар надо загрузить, перезаписав сведения у существующего товара.

B> Либо скопом делаете инсерт/апдейт.

Да, это можно сделать для тех узлов дерева, у которых стоят соответствующие флажки.


Остался вопрос только в грамотном разделении всего этого кода на слои, классы и т.д.
Вот например, сгруппированные данные для отображения в виде дерева — это слой представления? Или это слой бизнес-логики?
По теории — дерево — это представление.
Однако, связь между импортируемым товаром и существующим товаром пользователь фиксирует (с помощью флажка). И эта связь сохраняется в БД.
Следовательно, связь (то есть по сути это узел дерева) — это объект бизнес-логики.

В каком слое лучше реализовать работу с этой связью?
В слое бизнес-логики?