mayton2019

Забыл сделать commit.

1:1 - это плохая идея с точки зрения БД. Создайте просто одну таблицу и разделите ее условно на 2 части.
Это будет работать быстро и эффективно. И никаких JOINS. Несуществующие поля - заменяйте на nulls.

C sequelize-typescript я не работал. Не знаю как оно там. Но лучше не создавать технических долгов еще на проектировании. Потом вам легче будет жить.

Ну если файл небольшой - то его можно раззиповать.
$ gzip -d ....

Попробуй оконные функции https://www.postgresql.org/docs/current/tutorial-w...
в частности row_number()

Индексы, будучи созданными один раз - остаются навечно.
Если из таблицы удалены данные (50%) - то примерно
столько - же данных будет удалено соотвественно и из индекса.

Дисковое пространство которое занимает индекс - обычно не освобождается.
Тут надо читать документацию по конкретной БД. Oracle может вести себя так,
Postgres - как-то иначе.

P.S. Интересная терминология. Съезжает...
P.P.S Лётчик?

Можно попробовать начать с поиска по LIKE выражению. Обычно этого хватает для небольших таблиц.

А сама постановка полно-текстового поиска - очень сложна в условиях. Например в том какие возможности поискового языка должны использоваться. Нужно ли учитывать национальные особенности языка. Стоп-слова. Стемминг. Лемматизацию. Как часто будут обновляться индексируемые данные. Это все - список экспертных вопросов которые надо проговорить. Если вы не знаете зачем вам это все - то наверное полнотекстовый поиск не нужен и like будет достаточно.

Есть простейший запрос SELECT * from Table.
...
Реально ли как-то ускорить в этом случае?

Есть много мест в application где может что-то замедлятся . И это не обязательно SQL. Это может
быть веб-приложение, которое медленно отрисовывает таблицу. Или это может быть сетевой канал
который медленно отдает данные. Чтоб заниматься оптимизацией - нужно точно-точно знать где
оптимизировать. Или это будут зря потраченные усилия. Кроме того для UI например важно
получение 1 page вместо того чтобы загружать миллиард строк. Поэтому нужно знать какой %
результата выборки вы хотите использовать сразу (сию секунду) после получения и что
можно отложить на потом. Мой опыт подсказывает что пользователь вообще не воспринимает
информацию больше чем 1 абзац текста. Поэтому разгонять UI для отдачи миллиарда строк
нет никакого смысла.

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

id name     path  parent
-----------------------
1  Беларусь 1     null
2  Россия   2     null
3  Минск    1.3   1
4  Москва   2.4   2
5  СПБ      2.5   2
6  Невский  2.5.6 5

Ну а дальше - select... connect prior и получим ранжированый курсор по дереву. Там-же будет
доступно виртуальное поле level. И обходом этого курсора можно сделать JSON документ.
Если level растет - то увеличиваем indentation и открываем вложенный элемент соотв.

Если go-lang поддерживает stremable json writers то даже лучше.

Это скорее всего неправильно.

SELECT  name, number_plate, violation
FROM fine
GROUP BY name, number_plate, violation
HAVING count(*) > 1

если используется GROUP BY то в выражении SELECT должна стоять функция агрегации (count в данном случае)

Если ты говоришь о нормализации - то никак. JSON не предполагает никаких ссылочных связей внутрь документа. Считай что JSON - это денормализованная копия БД. Как с этим жить - большой вопрос. И его надо обсуждать поняв что тебе на самом деле нужно. Потому что конвертация EAV в JSON это какая-то странная очень узкая задача. Может тебе на самом деле это и не надо.

Сколько запросов в секунду - наперед никто не знает.

Для оценки обычно берут аналогичную систему и пытаются как-то экстраполировать.

В любом случае, если вы создаёте что-то новое - от вас требуется POC и бенчмарк. Без этого вы будете неубедительны.

Предположительно он просто не находит 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. Но будьте внимательны. Оба этих продукта имеют бесплатную и платную функциональности. Очень часто начинающие прокалываются на чтении документации и думают что фича есть. А на самом деле она - платная.

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