d-stream

Просто инициатором соединения должен быть клиент за nat. Типа он открывает соединение и в нем уже ждет команды от сервера.
Ну а "транспорт" команд - по вкусу от одиночных пакетов (ответы прилетят через nat) до persistent line любого типа... Хоть soap.

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

https://ru.wikipedia.org/wiki/Loopback
Либо в локальном dns/hosts прописывать для доменного имени локальный адрес

Процент получаю за разработку ПО. Я разрабатываю по ТЗ, инвестирую свое время взамен на процент с прибыли

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

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

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

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

Как уже отметили - самое худшее что может быть - это набортный RAID на полудолларовом чипе. Ровно как с морской свинкой, которая и не хрюкает и не плавает...

То что касается сохранности данных - raid обеспечивает только один из множества аспектов сохранности - обеспечивает целостность данных при сбоях одного диска. Естественно это совершенно не касается ситуаций с кривой реализацией типа использования десктопных дисков в аппаратном варианте массива (включая набортный чип) и наоборот - использования RE носителей в софтрэйде.

Но raid - это только один из множества аспектов оперативной сохранности. И в общем-то только в случае комплекса мер. Как минимум регулярных бэкапов с интервалами короче чем допустимые потери свежих данных.

А вот шифровальщики, косяки программ и т.п. - им raid без разницы.

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

Ну или совсем бюджетно - Microsoft OneDrive из коробки с win10, skydrive, dropbox, Yandex и google диски и т.п.

По-моему MySQL умеет pivot - тогда это лучший вариант.

А потом окажется, что половина подключений не по имени, а по ip )
В принципе Максим Гришин описал возможный костыльный вариант...

p.s. Я бы еще добавил изоленты на эти костыли: создаем в dns/hosts запись fiction_sql_server, указывающую на текущий сервер и все-таки правим все подключения на fiction_sql_server\sql2008express. После устаканивания и стабильности подключения - меняем в dns адрес на адрес нового сервера и profit

Есть еще ведь таблица "контрагенты"? (Ну или будет)

Так вот сотрудник - это контрагент + рюшечки касающиеся прав доступа и т.п. Притом временами контрагент-физик может стать еще и сотрудником и наоборот...

Онлайн-касса подразумевает ее регистрацию в налоговых органах - то есть прежде чем клиенту будет выдан первый чек в налоговой инспекции должна быть зарегистрирована связка "налогоплательщик - id фискального накопителя - [id (серийник) ККМ]"... далее разворачивать надо?

p/s/ в ФФД и 54ФЗ фигурируют конечно платежные агенты, но думаю у них тоже будет ступор с "передачей" денег физику...

Минимум три листочка в год - потребуется однозначно (декларация).

А договора - это гражданско-правовые отношения aka "правила разруливания ситуации в случае конфликта" по закону, а не по-понятиям.

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

Самый примитивный вариант:
оконными функциями вычисляем дельту между соседними событиями (например в минутах или секундах)

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

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

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

p.s. из практики - совершенно бесперспективный путь, если на входе не стоит шлюз-мельница под надзором двух суровых вохровцев.

Более перспективный вариант - можно предложить по более подробному описанию исходной задачи/проблемы

Например исторически-хронологическими причинами + оглядкой на свои внутренние архитектуры.

А не лучше ли рекурсивно брать всю цепочку, притом собирать рейтинг детей как avg например?

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

Ну а как следствие - те самые блокировки/отказы и т.п.

Даже в электрочайнике и кнопке смыва воды в унитазе используются алгоритмы. Разве что им редко присваивают божественный или персонифицированный смысл и поэтому не пишут их с заглавной буквы в середине предложения)

В энтерпрайзе IEEE 802.1X позволяет решить все проблемы. Дома\soho - не уверен что будет посильным по технико-финансовым соображениям.

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

Ну и еще можно поиграться с каждый порт - отдельный vlan или столь любимому раньше (да и сейчас) провайдерами PPTP (выкатив серый пул 10.0.0.0/8) -)

Формулировка вопроса идентична "мне скачаный файл не нужен, как закачать его обратно в интернет?"

У таблиц субд порядок вывода по запросу определяется либо явно order by в каждый момент времени, либо как субд удобно, приото каждый раз по-разному. А то что часто стихиный порядок повторяется -это всего лишь случайность.

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