d-stream

Почему регистрация домена и сам домен стоит денег?

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

Например за домен "******.com " я должен оплатить 10 USD. Кто получит эти 10 USD?

Те кто являются тем самым органом, выдающим этот домен и следящим чтобы этот домен не "взял" кто-то еще. Ну или их субдилерам aka ресселерами. Которые за счет опта имеют скидку и иногда регистрируют имена подешевле главного регистратора.

Возможно ли получить домен .com навсегда чтобы домен передавался по наследству)))

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

Кому принадлежат все не занятые доменные имена .com?

никому

Кто устанавливает цену на доменные имена?

Тот кто ведет их учет и регистрацию.

И как создать свою собственную доменную зону? (Например ******.mydomainname)

Обратится в ICANN

https://www.icann.org/resources/pages/faqs-2014-01...

Вообще хорошим тоном с точки зрения проектирования является отсутствие дубляжа. В данном случае производное из основных данных (остаток как разница поступления и расхода) является дублем.
На такое стоит идти только в угоду реальному повышению производительности.
Собственно расчет свободного остатка - штука быстрая. К примеру даже вычисляемое поле "есть ли свободный запас" при номенклатуре в 1.5 миллиона позиций и в среднем 3-4 уровнях деревьев замен/аналогов "вообще не заметно" в производительности. (MS SQL 4-8 cpu/vcpu 8-16-24 Gb RAM).

С ценами - чуть сложнее - схем ценообразования может быть множество. Поэтому лучше хранить "математику схем" и уже из этого вычислять условно конечную цену. А для нужд бухгалтерского, оперативного, управленческого учетов - вычислять в соответствии с теми нуждами.

Наверное вариант Dbase частично подпадет под такие критерии - типа плоские таблицы, подразумевающие relation - то бишь связи между таблицами, но по сути набор dbf-файлов (таблиц) способных существовать без схемы в виде "рассыпухи")

А вообще схема - это и есть отношения aka relation и поэтому реляционная БД в любом случае подразумевает схему, но можно их держать виртуально в голове, а не использовать механизмы БД для этого - получим реляционную БД без реляций)
Естественно последнее сродни обману таксиста - оплатить поездку, но не поехать)

например на .NET есть bogus преспокойно описываются требуемые сущности и их вариации и вперед - заливать в базу

Нормальный способ сериализация

Вообще - это reporting services, только точка "разделения" чуть иная - отчёты/шаблоны отчетов и на этом уровне регулируется доступ, а сами системы репортинга имеют доступ к базе или вьюшкам/процедурам
навскидку смотреть: Microsoft Reporting Services, crystal reports, stimulsoft reports, elastic kibana ну и все что сейчас позиционируется как bi

Можно поиграть с MPLS например или любыми другими методиками объединения сетей на L2. Только затея эта в любом случае порочна со всех сторон.

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

p/s/ резюме с портфолио запросов - сразу фтопку)

https://nginx.org/ru/docs/http/ngx_http_rewrite_mo...

достаточно ли будет коммутатора L3 Cisco SG250-26 для организации сети и разделения на VLANы? Можно ли как то сразу завести оптику от МГТС в него по SFP?

Это коммутатор. Соответственно еще потребуется NAT/Firewall.
Соответственно смысла заводить провайдерский конец в коммутатор - нет, его нормальное место внутри локальной сети - то бишь за NAT. Хотя конечно можно и извратится)

да
да

дергать таймером например

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

Во всех остальных случаях ситуации "два выхода, один вход" и т.п. - достаточно регулярная ситуация.

Чуть облегчает картину, если есть разделение событий входа и выхода...

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

В общем:
- первый уровень выбор 100% корректных выборок сотрудник-день
- автокоррекция очевидных некорректностей типа два входа подряд в течение минуты
- ручная коррекция остального

ну а дальше снюхивать это с табелями, потом зазоры-допуски на опоздания до 3 минут например, вариации допустимости сдвигов перерывов на обед и как именно трактовать (нарушение или нет) ранний на 3 минуты уход на обед, но возврат на 15 минут раньше и засчитывать ли в рабочее время то что сотрудник пришел на час раньше, а ушел на час позже и не ходил на обед))))))

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

p.s. без оконных функций такое считать тяжко

Собственно если не "сразу", то стоит ровно по шагам исходное-группировка - получившееся-группировка и так далее.

Плюс стоит ловить компромисс между читабельностью и производительностью. Чтобы не получалось как с регулярными выражениями, которые через день-два после написания уже нечитабельны... (привет от полной регулярки проверки email по rfc на пяток страниц)

Можно порыть в сторону вкладки "L7" в firewall
но не думаю что будет весело микротиковскими мозгами лопатить регэкспы для всех пакетов

Ну вообще зачастую для такого используют google protobuf