mayton2019

Да, можно. Вот константа Math.PI захардкожена в библиотеке математики и ни у кого не возникает с этим вопросов.

По поводу констант в Dagger2. Я с ним 1 раз поработал на проекте Java/AWS/lambda стека. Для простых проектов где требуется инжекторный двигатель, но Spring затаскивать - лениво, Dagger - самое то.

По поводу допустимо или нет - да допустимо. Тем более что ты пишешь что "один раз на проект". Вот к примеру имя таблицы. Ну кому в голову придет его менять? Это объем работ на самом деле в сто крат более тяжелый. И даже не в Даггере дело а в том что таблица к тому времени станет слишком родной для environment и дешевле будет поднять новую таблицу чем переименоввать старую. Уж повертье так оно бывает.

Передавать через конструктор или нет? Смотри если для модульных тестов тебе надо их менять - то передавай через конструктор. Если тесты не нужны на эту компоненту - то делай как проще.

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

Порадовала фраза:

Я хочу применить свои навыки (mysql, postresql docker, python) в текущей работе.

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

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

По Python - что есть то есть.

По виртуализации. Если у тебя есть контейнеризация где всё работает - то виртуализация тебе нафиг не нужна. Виртуализация вообще это продукт который давно устарел. Да и нерационален он в части ресурсов. Поэтому бери docker (compose а лучше kubernetes). И поднимай там сразу всю инфраструктуру. Кстати это автоматически закрывает вопросы всяких выделенных линуксов.

Я думаю что твоя идея не лишена смысла. Можно на каждого пользователя поднимать экземпляр БД.
Что здесь хорошо изоляция и безопасность. Что здесь плохо обилие linux-процессов на каждого пользователя. Например если у тебя чат на 10 000 человек - то поднять столько-же процессов на одном хосте сложнее. Любые операционки имеют какой-то минимальный футпринт памяти и ресурсов ОС на процесс. И переключение. Планировщик будет бегать между 10 тыщ процессов обслуживая их события. Что еще может быть плохо. Администрирование этого грида приложений. Бэкап проще делать имея 1 сущность процесса и 1 лог ошибок. А что делать с 10 тыщами логов. Отвественый девопс должен как-то просмотреть все логи? Или уже начать писать автоматизацию бэкапов. Кажется пустяк - но ты сядь и просто попробуй сам это сделать. Или мониторинг. Как проверить что все 10 тыщ не содержат в логах ошибок?

Вообще маппинг между приложениями и БД всегда идет сложным образом. Обычно m : n. И очень редко удается сделать 1:1 или как-то по другому.

ООП - это более аккуратная разработка с использованием приципов SOLID, KILL, YAGNI (это аббревиатуры) и если вы - 1 разработчик то вам будет очень сложно дисциплинировать себя чтобы следовать ООП. По смыслу это выглядит - как очень сильная формализация логики чтобы не было 1 длинной простыни кода а были небольшие сущности по 5-7 строк и каждая из них обладала бы 1 единственной зоной ответственности.

По большему счету польза от ООП проявляется на очень крупных проектах (больше десятков тыщ строк кода) и где много разрабов одновременно кодят и вносят изменениея.

Если у автора - мелкий pet-проект то возможно ООП ему и не нужно.