mayton2019

Предположительно он просто не находит liquibase-changelog.yml. Попробуй переложить его в другое место. Или изменить путь без classpath.

Вот здесь что-то не то.

ALTER TABLE country ADD CONSTRAINT country_fk0 FOREIGN KEY (IdCountry) REFERENCES city(IdCountry);

Тут таблицей промахнулся. Или направление констрейнта должно быть наоборот. Города ссылаются на страны. Но не наоборот.

Какой формат данных (JSON или JSONB) лучше использовать в этой ситуации?

Похоже автор занялся любимой задачей скучающих разработчиков. А именно - ПРЕЖДЕВРЕМЕННОЙ оптимизацией.

JSON и JSONB возникли например из задачи хранения в БД ДОКУМЕНТОВ. Документ - предполагает специфический юзкейс. Например однократное создание и редкую модификацию. И частое чтение с поиском по текстовому индексу например.

Является ли задача автора - подходящей под данный use-case? Чорт его знает. Я-бы сказал что пока нет. Все таки комментарии пользователя это такие себе... частые модификации документа которых хотелось-бы избежать.

И вообще пока не будет создано 2 макета или 2 proof-of-concept с бенчмарками - мы не можем точно сказать что лучше.

Сам-же Бартунов например в одном из своих докладов рассказывал что сама идея затащить в PG документы возникла из идеи работать с properties в одном поле. С такой себе неструктурированной информацией. А сама задача вознила из прикладной проблемы в дизайне базы для системы образования. Им нужно было хранить в строке неспецифицированный лист атрибутов. Это еще не JSON но уже дедушка его. Вот его так порешали. Это похоже на кейс автора? Я-бы сказал что далеко нет.

Вообще чтоб доказать или опровергнуть огульный тезис о JSON-ификации я-бы довел постановку до абсурда. Зачем мы будем трекать комментарии в JSON. Давайте и посты туда-же. И странички. И вообще всю модель положим в 1 документ JSON. Каково а? У нас будет база с 1 единственной JSON строкой которая хранит в себе всё. Технологично? Да. И не запрещается.

Вот как-то так.

Да вы правы. Здесь liquibase вполне себе подходит. Можно брать более модный flyway. Но будьте внимательны. Оба этих продукта имеют бесплатную и платную функциональности. Очень часто начинающие прокалываются на чтении документации и думают что фича есть. А на самом деле она - платная.

Но для простого юзкейса (без откатов) возможностей бесплатной части вполне хватит.

Можешь сразу после создания таблицы - вставить в нее 10 строк и тут-же удалить. :)

В любом языке или системе программирования всегда есть функция которая получает из буквы ее код таблицы ASCII (или в наше время Unicode). Все английские и служебные символы будут в диапазоне от 32 до 127. Русские - соотв не попадают в этот диапазон.

SELECT ascii('x');

Проверить все буквы в строке - дело техники. Или другая задача.

Перетащил это всё на MongoDB с такой структурой:

Справочники остались в MySQL.
.......
Какие есть идеи?

Думаю попробовать перенести структуру на PostgreSQL аналогично MongoDB и использовать

Дружище. Так жеж не делается в мире Документно-ориентированных БД! В монге ты делаешь не таблицы. А хранилища документов. Где каждый документ - самодостаточен и полностью хранит в себе всю информацию. Грубо говоря никаких СПРАВОЧНИКОВ и СВЯЗНЫХ таблиц у тебя быть не должно. И нельзя джойнить документы. И нельзя джойнить документы с таблицами MySQL.

Почитай про модель АГРЕГАТОВ в противовес реляционной модели. Это можно найти в книжках типа NoSQL и еще я находил это в доках по Cassandra.

Похоже на сетевую проблему.

Проведи диагностику на низком уровне. Пингуй хост DB_HOST.
Попробуй телнетом подключится к порту DB_PORT.

Потом - консолью
$ psql ....

По виду это похоже на троичную систему счисления. Ее можно получить просто пересчитывая нормальный sequence. Пишу на псевдокоде.

create table ПочемуАвторНикогдаНеПишетНазваниеТаблиц (
   id sequence,
   class_id int GENERATED ALWAYS AS (id / 3),
   student_id int GENERATED ALWAYS AS (id % 3)  
);

Что за вертикальная палочка? Зачем она?

ALTER TABLE sl.lesson {
    DROP CONSTRAINT lesson_timetable_id_fkey |
    DROP COLUMN timetable_id
}

А это что?

liquibase.exception.ValidationFailedException: Validation Failed:

Изменял change-sets грязными руками? Этого нельзя делать. То что установлено в репо - маркируется контрольной суммой и нельзя фиксить задним числом. Создаёшь новый changeset который исправляет.

Можно так попробовать

CREATE EXTENSION pgcrypto;

BEGIN;
 // Partition 1 of 16
 UPDATE .... WHERE left(digest(ID, 'sha256'),1) = '0' 
COMMIT;

BEGIN;
 // Partition 2 of 16
 UPDATE .... WHERE left(digest(ID, 'sha256'),1) = '1' 
COMMIT;

У Oracle была более простая функция hash(...) которая разделяла сет ключей сразу на известное число партишенов. Там второй аргумент указывался. Но в PG я не знаю аналога. Может знающие подскажут.

Для баз данных существует еще больше способов виртуализации. Кроме docker/kuber можно создавать много баз данных в одном и том-же хосте (pod). Но подумайте будет ли вам удобно бэкапировать такой будерброд. И не будет-ли проблем с безопасностью если кто-то будет создавать в одной базе public объекты.

Tayrus0 почитай еще про оконные функции. Ключевые слова ROW_NUMBER(), PARTITION BY.