d-stream

Ну например изучить чуть-чуть то что приводится в примерах книжек или msdn на предмет MVVM - там как раз примерно в середине подходят к форме с гридом, полями для редактирования и кнопками.
По сути все, кроме конкретики модели получается практически стандартно-единообразно, не считая рюшек визуального оформления.

Более-менее оптимальный вариант в близком решении (обновление прайсов на 0.5-20 миллионов позиций):

1. из внешнего источника данные втягиваются во временную таблицу
2. из временной таблицы в номенклатуру добавляются отсутствующие (новые) позиции
3. временная таблица прореживается на предмет дубликатов
4. временная таблица прореживается по ряду интерактивных условий (какие поля из нее использовать для обновления) - совпадающие удаляются
5. пачками делается update - именно пачками, специфичными для каждого экземпляра sql сервера с его загрузкой, объемом памяти, скоростью дисковой подсистемы и т.п.

экспериментальным путем - пришли где-то к размеру "пачки" в 50000...200000 строк

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

Еще лет 10 назад обычно над админами блокирующими почту по всяческим блэклистам как минимум смеялись.
Иногда приходилось на таких админов матюкаться...

В общем не надо информацию из блэклистов использовать как руководство к дропу почты.

Балл повышать - можно, но с осторожностью. Да и то чуть-чуть.

На данный момент я не придумал ничего лучше, как генерировать при загрузке файла GUID и, например, для 6F9619FF-8B86-D011-B42D-00CF4FC964FF хранить фото в папке 6F/6F96/6F9619FF-8B86-D011-B42D-00CF4FC964FF.jpg. В БД я планирую хранить только GUID, а загружаемый формат для картинок ограничу одним JPG. Сильно ли костыльно?

Собственно подход не нов. Та же WSUS хранит контент именно так, правда ей хватает всего одного уровня вложенности.

Товары?
Тогда храните поступления (партии) и расход (списания), а количества - вычисляйте.

А варианты выбора шрифтов с гарантированной кириллицей не прокатывают?

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

Первый этап абстрактно можно возложить на нечто типа AI, но это потом немного сильнее нагрузит второй этап...

По-моему наиболее читабельный и вполне оперативный - разделить insert и update, что собственно merge с другого профиля. По крайней мере пока про insert or update - ms молчит как рыба об лед...

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

На сегодня с точки зрения "использования" разница весьма зыбка, ибо зачастую с-код компилируется cpp-компилятором с флагом "работать в режиме С"

Остальное - уже принципиально зависит от конкретных прикладных задач: hello world скомпилируется что на с что с++ под практически любые вычислительные устройства, а вот какая-нибудь жутко хитрая конструкция нестандартного использования железа южного моста - просто и не будет требовать компилировать на всем, а скорее даже требовать конкретную версию чипсета и т.п.

По логике C++ вырос из С и в любом случае практически везде изложение "про С++" органично подразумевает, что читатель вполне адекватно владеет С - отсюда очевиден вывод.

Например https://metanit.com/sharp/tutorial/ коротко, читабельно. Почти справочник.

ФФД 1.05 и 1.1

грубо
1. Реквизит «Признак способа расчета» (тег 1214) - 7 вариантов (предоплаты-авансы-кредиты) и среди них финишный №4
2. «Наименование предмета расчета» (тег 1030) - 12 вариантов
3. Задается фискальный тип оплат как "зачет аванса"

Там же в п.3 можно задать типы оплат типа фантиков, бонусов и т.п. но я бы это исключил и в чек гнал только цены и суммы "с учетом всех скидок и наценок" (с) инструкция ФНС

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

Более-менее реалистичный путь - делать новые и заменять старые достаточно автономные формочки новым интерфейсом...

Делаем бэкап базы, поднимаем ее копию и издеваемся над копией

Может сразу посмотреть в сторону reporting services ?