Frozen Coder

Надо смотреть на данные и как они будут использоваться. Если они полны отношений, т.е. носят ярко выраженный реляционный характер, вам нужны запросы с join и транзакционностью, то берите MySQL и всё. К тому же в MySQL есть возможность хранить JSON и вроде даже индексы по нему строить.

Mongodb брать хорошо, когда у данные можно выразить через документ. Т.е. по максимуму все связанные сущности встроить в один документ. Join по факту надо делать руками, т.е. через приложение. Многие фишки реляционных БД как бы есть, но работают похуже, чем в реляционных (есть и схема, и транзации и вроде join, но это такое, лучше избегать по возможности).

Во-первых, ваш конструктор в Animal не имеет смысла в том виде, в котором вы его привели - без аргументов вы просто поля класа переприсвоили сами в себя, наверно вы забыли написать аргументы у контруктора name и age.
Во-вторых, Александр Варакосов неправ и контрукторы не наследуются.

В java есть конструкторы по-умолчанию - контруктор без агрументов. Он создается компилятором автоматически, если у класса не объявлено ни одного конструктора.
В конструкторах дочерних классов компилятор сам вставляет первой строкой вызов родительского контруктора по умолчанию, при наличии такового в родительском классе. Т.о. если у дочернего класса нужно в конструкторе просто вызывать конструктор родителя по умолчанию, то в дочернем классе можно явно не объявлять никакой контруктор. А вот если у родителя нет конструктора без аргументов, то объявлять конструктор в дочернем классе необходимо, хотя бы чтобы вызвать в нём родительский конструктор.

P.S. и ещё прочитайте про модификаторы доступа. В java принято поля делать private + getter/setter по необходимости. Вообще, возьмите какой-нибудь учебник по java, там всё расписано

Прочитайте последнюю версию Effective Java. Как подсказал illuzor , уже есть издание на русском

Статей по мавену полно, пары хватит, чтобы понять. Он простой.

Ещё немного официальных видосов подкину вам - https://www.jetbrains.com/idea/documentation/

Кроме того, в самой IDEA есть хороший официальный плагин - https://plugins.jetbrains.com/plugin/8554-ide-feat... . Это серия мини-упражнений, выполняя которые, знакомишься с основными фукнциями IDEA

Есть плагин-помощник в запоминании хоткеев - https://plugins.jetbrains.com/plugin/9792-key-prom...

Ещё есть видос от Вячеслава Ковалевского по хоткеям в IDEA - https://www.youtube.com/watch?v=9kqKMFekI9Y&list=P...

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

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

Далее, вам какую задачу решать? Язык выбирают под проект, под задачу, под требования, а не проще. Если говорить о коне в вакууме, то попробуйте Python

Как вам уже заметили в комментариях, вам необходимо погуглить назначения методов HTTP, ибо метод GET вы используете некорректно.

Про сессию уже написали. Ещё вариант - это использовать local strorage на стороне клиента и писать-читать из него (немного поработать с js).

Если варианты выше не подходят, то можно в отдельной таблице хранить проекты заявок. Т.е. пользователь сначала создаёт проект заявки первым запросом - сохраняем его в отдельную таблицу, а потом на каждом шаге в эту запись добавляются данные с отдельных форм. В финале этот проект становится заявкой - удаляется из таблицы проектов и переносится в таблицу заявок. Это решение не зависит от состояния сессии и local storage. Пользователь может продолжить заполнять заявку с другого клиента в другой сессии, ведь мы храним его проект у себя в базе. Как бонус, таким макаром можно при необходимости организовать пользовательские шаблоны заявок (если форма большая и пользователем большая её часть вводится одинаковая), чтобы быстро создавать новые заявки из сохранённых шаблонов.

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

Ещё вариант, если у вас есть html, который не меняется по ходу изменения форм (т.е. вы просто меняете куски страниц при переходе по формам), то можно завести скрытые поля, куда дублировать заполнение формы пользователем. В итоге у вас эти скрытые поля заполнены и именно их содержимое отправляется на сервер в итоге. Видел такое на старых проектах.

В проектах с SPA такой проблемы нет, т.к. в таком случае на клиенте просто выполняется управление состоянием и роутингом

Что мешает создавать их по мере необходимости? Более того, можно вообще сделать один убер-контроллер, который будет отвечать на всё, но никогда не делайте так :)

Контроллеры надо разделять по области их деятельности, по той проблеме, которую они решают. Он может отдавать не только же страницы, но и json'ы какие-нибудь - у вас же на странице может быть динамическое содержимое, которое нужно получать без перезагрузки всей страницы. А вдруг оно нужно ещё и на другой странице? Например список пользователей. У нас есть страница для отображения списка пользователей и мы в котроллере пользователей отдаём эту страницу, но где-то на другой странице тоже нужно отобразить список пользователей или вообще отдать просто через REST другой системе, логично метод, возвращающий json-списка пользователей разместить в этом же контроллере.

Другой путь поделить ваши контроллеры на котроллеры, которые отдают страницы и контроллеры, которые отдают json. Это, можно сказать, вкусовщина.

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

А если вы работаете в паре с фронтендером, то обязательно обудите с ним, какие ему нужны API и данные на клиенте - это также поможет вам решить ваши вопросы с контроллерами.

А сходите в армию, там за вас всё решат, что вам делать и куда развиваться. А можно в универститет. В 18 лет самое то, в какой-нибудь столичный. А может стоит уже взять отвественность за свою жизнь в свои руки и самому решать? Вам вот всё нравится, а что из этого всего вы делали руками? В каждой области уже по проектику написали учебному? Вот как, скажите, пожалуйста, как люди из интернета могут за вас решить, что вам понравится и что вам делать? Мне вот нравится на java кодить, вы тоже кодьте на java - такой совет вам нужен? Попробуйте всё понемногу, делайте-делайте-делайте, а не просто читайте. Найдите то, что вам действительно нравится и по кайфу и по максимуму вкладывайтесь туда. Если будете бежать только за деньгами, то однажды проснётесь с осознанием того, что ненавидите свою работу и жизнь, и пойдёте строчить статью на eb-e.it о том какое IT гуано. Серьёзно подумайте о переезде либо готовтесь вертеться как уж на сковородке, чтобы получить удалённую работу - работа в провинции, чаще всего, такое себе безальтернативное болото.

IDE тут вообще не при чём. Всё можно хоть в блокноте делать.
Для генерации проекта с кучкой зависимостей, которые вы выбираете мышкой вам сюда - https://start.spring.io/ .
Разберитесь с maven и pom.xml, как подключить репозиторий. Всё, что вам надо знать - это название либы, дальше идёте в mvnrepository, ищите её и там даже код есть для копи-пасты - https://mvnrepository.com/repos/central. Например - https://mvnrepository.com/artifact/org.apache.comm...
Можете в jar запихать с embedded tomcat, можете в war пихать. IDE тут не причем. Всё можно делать в комьюнити. Не знаю, какие туториалы вы смотрите, но советую посмотреть на https://spring.io/guides - они простые, там всё описано по шагам, даже содержание pom.xml. Даже есть переводы - spring-projects.ru/projects/spring-framework

Вам нужно серверное приложение, которое будет предоставлять удалённым клиентам доступ к БД, но не напрямую, а через себя путём общения с клиентами по http с помощью REST (проще) или SOAP. Т.е. клиенты отправляют запросы и получают от сервера ответы. Сервер располагается (задеплоен) на удалённой машине в каком-нибудь облаке или куда вы его задеплоите. Там же рядышком будет БД, про которую будет знать только ваше серверное приложение, но не ваши клиенты. Клиенты знают только про приложение, вернее куда стучать, что отправлять и что ожидать в ответ.

Гуглить в сторону Spring Boot, Spring Data. Также скорее всего понадобится механизм аутентификации и авторизации, если вы хотите, чтобы с приложением могли работать только ваши клиенты. Тогда смотрим ещё и в сторону Spring Security.

Сначала почитайте про http, потом про REST. Если вам просто дёргать базу, то есть супер-простое решение - Spring Data Rest, которое сгенерит за вас все запросы и даже апи. Вам будет необходимо только сущности описать (почитайте про JPA и её аннотации) и объявить интерфейсы репозиториев и немного обвязки-настроек в properties прописать.

Вот наглядный простой пример: spring-projects.ru/guides/accessing-data-rest . Там есть исходники на гитхабе, возьмите их, потыкайте, перепишите под себя.

Когда будет готов сервер, то остаётся научить ваше десктопное приложение дёргать по http апишку вашего сервера - отправлять запросы и обрабатывать ответы. С десктопными приложениями не работал, но гугл вам легко подскажет какую-нибудь библиотеку http-клиента - okhttp какой-нибудь.

Не считаю себя хорошим программистом и профи, пока в процессе. Могу поделиться своим ИМХО.

Часть 1
1. Готовое использовать тоже надо уметь и знать, где это готовое найти, которое помочь может, какое готовое хорошо, а какое будет лишним.
2. П.1 не исключает возможности писать велосипед. Писать велосипеды полезно для себя, чтобы глубже разобраться в работе готового, в процессе подглядеть на готовый код, подумать как написал бы сам. Мб писать узкоспециализированные велосипеды, которые подойдут именно вашей задаче лучше, чем готовые, но универсальные решения.
3. Я работаю full-stack. У нас все такие, ибо народу не так уж много. Периодически устаю от этого, но периодически не представляю себя без возможности писать и на фронте, и на беке. Если вам по душе решать задачу от начала и до конца, то почему нет? Главное, чтобы в кайф. Возможно стоит в таком случае развиваться периодами - выделяем период и изучаем это направление, потом переключаемся на другое. А возможно надо отталкиваться от конкретной задачи и в её рамках изучать как решить её на клиенте, а как на сервере. Чтобы переключаться и читать любой код, надо обладать широким кругозором и знать базовые концепции, Computer Science, паттерны, парадигмы и т.п. Чтобы делать это быстро, нужен опыт. Когда однажды решал что-то подобное, то второй раз решить это будет проще и быстрее. Ещё полезно держать руку на пульсе и слушать, что сейчас в IT вообще твориться, чтобы знать куда копать, если возникнет необходимость - я покрываю это подкастами и статейками из всяких еженедельных рассылок.

Часть 2
1. Английский каждый день, хоть 10 минут, но каждый день. Читать, смотреть, слушать. В идеале ещё и говорить.
2. Дискретка - да. Например, есть книжка Дискретная математика для программистов. Вышка, матан - ну хз, смотря, что за задачи решать, большинству не особо то и пригождается.
3. Алгоритмы и структуры данных - да. Какие-нибудь классические книжки по этому делу. Кормен, например. Но вот тут, имхо, нужно писать велосипеды! Изучаете алгоритм или структуру данных, описание на естественном языке, а потом берёте ваш любимый ЯП и реализуете этот алгоритм по описанию сами. Затем ищите в интернете его "эталонную" реализацию, сравниваете с вашим велосипедом. Как книжку пройдёте, то мб захочется углубиться в какую-нибудь сферу Computer Science. Ещё есть Open Source Univercity - https://github.com/ossu/computer-science - это сборник лучших бесплатных материалов по CS в сети, как бы онлайн-образование в сфере CS. Сам не проходил, но в планах туда заглянуть есть)
4. Паттерны, как и п.3
5. Изучите пару ЯП с парадигмой, отличной от привычной вам.
6. Если вы в web, то надо познать как работают сети.
7. В идеале познать ОС, в общих чертах как устроена, как работает. Команды оболочки, поадминить какие-нибудь сервисы в мини-сети из виртуалок, пожить немного чисто в консоли.
8. Принять участие в Open Source. Вы же пользуетесь готовыми штуками. Возьмите небольшую такую штуку, посмотрите как она устроена внутри, сходите на её гитхаб, посмотрите issue, мб там нужна ваша помощь. Часто есть issue, отмеченные для новичков. Тут одни плюсы - разберётесь в готовой штуке, сделаете её лучше для себя и для других, получите гордое звание контрибьютора).
9. Не слушать таких людей, как ваш начальник - это у него не получится, а вы на себе крест не ставьте, вам до пенсии ещё кодить и кодить.
10. Ну и писать код, больше кода богу кода.

Если мы говорим про react-router, то можно с его помощью сделать несколько вложенных Switch. Т.е. где-то наверху у нас главный Switch, роуты которого ведут на компонты категорий по начальному url типа 'home/:category', в этом или этих компонентах категорий есть ещё один Switch, роуты которого ведут на компонт(ы) подкатегорий, где есть ещё один Switch. Что-то типо такого. Тут детали зависят от того, как сделаны эти дочерние компоненты - один на категорию или один на все категории.