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 молчит как рыба об лед...