d-stream

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

Я бы вообще убрал Dispose, особенно в первом варианте с using.
Это как-то imho более в стиле шарпа.

Триггеры - фактически единственное, что обеспечит своего рода "целостность" задумки на уровне БД.

На уровне условного соглашения "не суваться к базе" мимо хранимых процедур - можно реализовать аналогичное на уровне ХП, но это не php-style -)

ROW_NUMBER()
https://msdn.microsoft.com/ru-ru/library/ms189461.aspx

Хватает, если надо где-то по-быстрому поработать или лень к столу с парой 25" мониторов идти.

Использовать штатные функции преобразования timestamp в дату/дни/года уровня библиотеки или базы данных.
Большие дядьки там уже давно и успешно (ибо неуспешные продукты уже забыты) все оптимизировали и даже предусмотрели високосности, лишние секунды и прочие хитрости.

Можно посмотреть в сторону блоков бесперебойного питания для скд. К примеру: www.tinko.ru/p-212456.html - в нем вполне хватит места для преобразователя 12в в 5в и малинки с обвесом.
Ну а 7/9АЧ аккумулятор обеспечит достаточное время автономности.
Сама конструкция блока питания с цепями заряда уже давно вылизана временем и подобные коробки успешно работают десятилетиями. Если поискать - можно найти ББП и сразу с USB-питанием.

Гуглить GeoIp|Geobase например
только часовые пояса - это как бы следующая за геопривязкой задача.
Естественно все это обладает частичной точностью, ибо:
- иногда принадлежащие организации с определенным географическим положением размазываются по географически разнесенным филиалам
- иногда владельцы ip адресов меняются

Написать велосипед сервис/сервер, который будет с одной стороны взаимодействовать с программами, с другой писать файл на диск, а внутри - кэшировать это.

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

SQL придумали как почти естественный язык "попросить у базы":

select [выбрать]
* [все]
from Users [из Users]
where [когда/где/которые]
gender = Female and (today - birthday) < X [ женщины и возраст меньше х]
or (или)
gender = Male and (today - birthday) < X [мужчины и возраст меньше х]

Работает. Только моя телепатия подсказывает, что balans - строковый а пытаются хранить в нем цифры и потом возникает удивление почему 100,01 располагается не так рядом со 100,11

Не лучше ли использовать binding ?

СБ в меру своей задачи - отслеживает совершенно разными способами. Начиная от технических, что выше перечислила и заканчивая социальными (от стукачей на фирме до фейковых аккаунтов в соцсетях).

У снабженцев - классическая засада в виде фейкового контрагента-поставщика и вылет по результатам обсуждения откатов например -)

Резонный вопрос: а нафига? Это же сродни "ща запилю свою ос со своим ассемблером sql и компилятором" -)

Более-менее большие SQL-системы зачастую славятся именно тем, что в каждый конкретный момент времени (запрос) могут в том числе на основании статистики, памяти, загрузки построить разный план выполнения одного и того же запроса. Именно с целью его оптимизации.

Очень упрощенно, но в правильном направлении.

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