Александр

Mikrotik

Unsupported class file major version 66
Тут написано, что 22я джава не поддерживается.
Попробуйте установить какую-нибудь предыдущую версию.
Рекомендую пробовать lts версии по порядку: 8, 11, 17, 21

Например, для обслуживания миксросервисной инфраструктуры (типичные эндпоинты /actuator/; /actuator/health; /actuator/info)

Да. Такие эксперименты были. Лет 5 назад когда был еще жив sql.ru, один человек продвигал
модель т.н. квинтетов. Это таблица с 5 полями которая полностью описывала любую
доменную область. Я к сожалению не могу нигде найти следов описания этой системы
но возможно это оно https://cyclowiki.org/wiki/QDM . Читайте смотрите.

Второе. В эпоху новых версий DBMS (Oracle/PG/MySQL) когда мы можем использовать
JSON/XML внутри ячейки, сама идея EAV теряет смысл. Поле атомарно? Атомарно.
Значит законы реляционной алгебры мы не нарушаем и JSON совершенно легальный
тип для реляционок. Хотя лет 30 назад его использование было-бы кощунством
в БД. Но это можно было списать на жесткую экономию ресурсов и чрезмерную
математичность моделей Бойса-Кодда. Сегодня все используют JSON и нет никаких
архитектурных доводов против. Поэтому создавайте NoSQL табличку где есть
key и есть значение в виде либерального типа документа. Как делают MongoDb, CouchDb.
И если связать их в иерархию то получится вполне себе те-же самые квинтеты.

Про EAV лучше забудьте. Их любят преподаватели SQL и теоретики. Но практически EAV
слишком медленно работает чтобы развивать его в бизнес-приложении или в промышленности.
Мир тяготеет к упрощению. И поэтому JSON - это упрощение EAV. И работает быстрее.

iptraf (iptraf-ng)
tcpdump

///После недельного простоя, мне звонят и приглашают на стажировку////
Значит, опытные спецы за ту зп, которую они предлагают даже не откликаются. Взяли Вас "На стажировку". Это и правда и нет, одновременно. Вы друг друга нашли, скажем так.
Выжмите максимально опыт в практике из этой хитрой конторки. Главное - не сильно себя вините, если что-то сломается, а на вас будут наезжать. Отвергайте любые обвинения в случае простоя. Далее, как поднатореете, через месяцев 12 ищите нормальную, которая понимает объёмы и ответственность IT-специалиста за простои в работе и платит в ~2 раза больше.

По теме вопроса: первое, на что обратить внимание - на критичность того ии иного сервиса. Прям подойти к боссу и спросить - "что должно работать весь рабочий день?". Телефония? БД? 1с? Без чего прям кранты? К тому сервису и направьте своё максимальное внимание. Смоделируйте на практике восстановление БД из резервной копии. Файловый сервер. Сотрудник уволился, грохнул все свои наработки/файлы, логины на торговых площадках, почтовую переписку etc. Промониторить доступы предыдущих сотрудников на администратиыный доступ к каким-либо сервисам/серверам/роутерам/площадкам.

Ответ оказался до жути простым
Я забыл добавить модуль своих моделей в main.rs файл:
mod entities;

В реляционных БД не существует гарантий относительно порядка записей внутри таблицы. Этот порядок
- это особенности технической реализации хранения данных внутри блоков и сегментов. Это - "know how"
и это будет зависеть от типа DBMS (Postgres, MySQL, Oracle) и от типа таблицы (heap, index-organized, clustered e.t.c)

Если говорить грубо, то записи (data-rows) лежат не плотно а вразнобой с пробелами с выравниванием
к блокам. Ну тоесть вообще-вообще не так как в Excel. Удаление data-rows в Postgres насколько я помню
физически не удаляет запись а помечает ее мертвой используя служебные поля. Впоследствии VACUUM
делает работы по уплотнению.

Поэтому порядок ты сам обеспечиваешь, делая запрос с опцией ORDER BY some_date_time.