d-stream

Тупой пример:
есть поля цена, количество, сумма

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

притом это не потребует выискивать все места где идет присвоение значения полю (потому что все в сеттере)

3. Реально ли каждого пользователя загнать в AD?

немалое количество людей удивится - "а что, бывает иначе?"
Впрочем предприятие на десяток компов - можно и не так...

У всех действий должна быть какая-то осмысленная цель. Просто так загонять в AD - наверное действительно нет смысла. Значит тс еще не созрел что можно админить головой, а не ногами)

Терминалы - опять же - все не просто так потому что захотелось... и денег это не экономит...

"captive portal mikrotik" - первый десяток результатов в поисковике - практически готовые решения

кстати по mac - можно нарваться с частью телефонов, которые рандомно меняют mac..

1. доменное имя регистрируется не на адрес
2. virtual host - это умеют большинство web серверов и не надо даже городить несколько компьютеров за nat - достаточно одного, который будет обслуживать хоть 100500 разных сайтов.
Притом большинство web-серверов с давних времен заточены под это с хорошим разделением уровней полномочий.

Классика:

update table
set 
filed_n = case when условие1 then значение/выражение else field_n end
filed_m = case when условие2 then значение/выражение else field_m end
where ….

С insert - собственно аналогично, только в case негативная ветка будет содержать null

GRANT EXECUTE on xp_cmdshell to sql_user

И?
Еще одна колонка в таблице is_deleted и соответственно в нужных местах в where is_deleted=0

….

upd, точнее лучше сразу nullable delete_date - и в условиях соответственно (delete_date is null or delete_date <= threshold_date)

USB-VGA пригодится в тот момент, когда потребуется подключить еще один монитор
То есть первый внешний монитор - D-Sub/HDMI/DVI, второй-третий - через usb-vga

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

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

То есть для РФ +7 (900) 100-00-00 , +7 (8765) 22-99-99, + 7 (876-55) 5-25-25, а эти же номера для немца окажутся 007 900 1000000, 007 876 5229999, 007 876 5552525,

а для усть-урюпинска - могут быть как:

8 900 100-00-00, 8-2 22-99-99 и 5-25-25

хотя в базе - это будет 3+ поля

в принципе хранить имеет смысл как int, а для "хитростей" поиска по частичным маскам - просто держать вычисляемые поля, где номер кастится к [n]varchar

SQL оперирует строками. В принципе на этом точка.
Остальное - танцами с insert|update

Ну или как вариант для разреженной таблицы:
(row_id, col_id, value), где pk: row_id,col_id

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

Наверное стоит найти "концы" по тому, что автоматизировалось - не исключено что все-таки сделали.

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

и на выходе сформировать нечто типа техзадания на разработку и реализацию приложения

после этого уже можно будет пощупать несколько разных разработчиков на предмет цен, сроков

и вот примерно после всего этого появится понимание "на чем писать"

Варианта два:
- либо выплевывать из источника blob в каком-нибудь варианте ascii кодирования (например base64)
- либо сделать нечто типа mssql -> скрипт умеющий подключаться к обеим базам-> mysql