d-stream

Можно тогда сразу шагнуть дальше - не нанимать питона из шарпа, а нанять программиста вместо себя =))

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

Два примера:
1. некий огромный набор данных, по которому нечто рассчитывается
в исходных данных ноль недопустим - exception подразумевающее "все пропало" и прекращение действий (выбран не тот файл и т.п.)

2. тот же набор данных
в процессе сложных вычислений за счет округления один из делителей может округлиться до нуля... если это предсказуемо и допустимо - можно ветвиться if-ом и присваивать результату такого деления "псевдобесконечность" - например максимальное значения int и т.п. и далее продолжать вычисления

Судя по описанию, самый "интересный" вариант будет - перемешивание: меняем местами случайно выбранные позиции... и так много раз. Количество элементов алфавита не меняется, но меняется их порядок.

В давние-давние времена баловались так с vga видеобуфером в текстовом режиме

Там уровней - много. Освещение салона и кнопки на руле - из самых верхних.
А в глубине, чаще всего - отдельное и достаточно изолированное realtime ядро (rtos, qnx based), еще точнее несколько независимых ядер под критичные системы и далее слои комфорта. Притом ядра - это отдельное железо, вплоть до совершенно отдельных коробок (модуль управления двигателем, модуль ABS, SRS, поверх всяческие ESP) разного уровня важности. Всяческие GEM - это уже самый последний и наименее приоритетный уровень, "рулящий" освещением салона, переключением магнитолы и т.п.

Ну между собой все это общается по нескольким can-шинам, до части которых можно добраться непосредственно, а до части - только через привратника в виде центрального ECU

И да, не все производители и не всегда делают СУД качественно... можно найти в интернете разбор сотен тысяч косяков тойотовского ПО например -)

Есть общие соображения по срокам устаревания ключей, паролей и т.п. (они могут банально утечь например)
Думаю, что сама мысль, что их надо менять время от времени не вызывает отторжения?
Ну а дальше традиционный срок - год.
Иногда в прайсах УЦ фигурируют и большие сроки, но практика сводится к тому, что мало кто выбирает варианты больше чем на год. Это и дешевле и в общем-то практичнее в плане динамичности прогресса в данной сфере (через год могут появиться иные ключи, изменятся форматы и т.п.)

Ну например изучить чуть-чуть то что приводится в примерах книжек или 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 можно задать типы оплат типа фантиков, бонусов и т.п. но я бы это исключил и в чек гнал только цены и суммы "с учетом всех скидок и наценок" (с) инструкция ФНС