d-stream

Вариант 2 ближе к реальности.
Только по факту некоторые статусы могут быть не совсем чтобы bool
Например та же доставка может оказаться как "комплектация", "сборка", "упаковка", "передача курьеру/тк", "доставка"
Да и оплаченность по большому счету может быть разной "предоплачен", "есть копия пп","деньги поступили"

Все зависит от прошлого опыта (подготовки). Если их нет - то наверное смотреть книги по основам ООП и C# и далее уже углубление в сторону нынешнего C# 7.0 (впрочем если изучить 5, то потом фичи 6,7 окажутся просто полезным сахарком)

Так же стоит смотреть в сторону WPF, это хорошо, но покажется несколько объемным для мелких задач.

Какой смысл прикручивания к велосипеду с квадратными колесами треугольных подшипников с бубенчиками?

Начать необходимо с исходного - какие требования к значениям. Фраза "мне только хранить" может вообще спровоцировать на "не хранить". Или же далее будет хоть какое-то использование.

А в нормальном варианте - decimal, либо real, но с четким пониманием чем реал хорош и чем плох.

Правильный путь - вязать к полям формы поля объекта, читать-сохранять - объект. Точнее научить объект сохраняться при необходимости и загружаться например при создании.

Извращенный - крутиться циклом по всем элементам формы и читать-писать пары имя-значение, потом иметь море секса при изменении/переименовании элементов -)

В чем проблема-то? Сотни тысяч строк - это для бд - не объем.

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

Ну или в другом ключе - по степени критичности для бизнеса: критика - своя, пусть даже и дороже, среднее - оутсорсерам, остальное - кому попало.

Ну или по народному: ёлочные гирлянды или пляжные тапочки - можно и по фото на али купить, магнитолу, хлебопечку, тостер - в более-менее приличном интернет-магазине, а вот кардиостимулятор - у пары-тройки производителей...

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

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

Два примера:
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 хранит контент именно так, правда ей хватает всего одного уровня вложенности.

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