mayton2019

Что там по сетевому доступу?

Сделай в консоли

$ nc -zv your-db-host 5432

Александр Богдашкин, если нет - установи ее под Windows. Синоним - netcat. В данном случая я проверяю доступ к TCP-сокету.

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

Если сокет закрыт - то нет смысла делать эксперименты с Бивером. Тебя просто файрвол не пускает.

UPD. Удалено лишнее.

Нужно добавлять в часы когда пользователи не работают с БД. И добавлять в несколько этапов.
Сначала просто добавить колонку. Потом ее дефолтное значение обновить. Это можно порциями делать.
Потом констрейнты и триггеры добавить. И смотри чтоб ты не пересекался с джобом который делает
вакуум.

Сколько времени - ждать ХЗ. Наверное в PG есть monitoring views которые показывают текущие активности.
Но это я не знаю. Пусть другие подскажут.

Ух. Нет предела совершенству. Можно начать читать отсюда https://www.postgresql.org/docs/current/index.html

Если спрашивают на собеседовании - то у них есть конкретная позиция или должность например DBA или разработчика. У них - очень разные задачи. Например DBA заниматеся бекапами, перформансом. Поднимает новые экземпляры БД для бизнеса. Лечит упавшие. Делает апгрейд версий софта. Вобщем поддерживает непрерывный цикл работы. Если спрашивают на разработчика (к примеру для банка) - то нужно знать режимы работы транзакций (их там 4 штуки кажется). Нужно знать и применять индексы. Оценивать когда они полезны и когда - бесполезны. Писать триггеры и хранимые процедуры. Если ты идешь разработчиком в какой-нибудь 2ГИС то будут спрашивать гео-поисковые возможности PG. Кроме того в наше время разработчик с БД работает малую часть времени. Все таки его основными языками будут Java/C# e.t.c. и фреймворки типа Hibernate. И нужно распределять усилия. Чистых БД разработчиков я уже лет 10 не видел. Поэтому стоит ли "упарываться" прямо в постгрес - ну я не знаю.

Вобщем PG - это очень старый программный продукт с большой историей у которого есть много расширений и знать их все сразу невозможно.

Есть организации и есть два способа построить бд это для каждой организации создавать копии таблиц с префиксом

Тебе повезло. У тебя - postgres. Создай для каждой организации отдельную базу.

CREATE DATABASE org1 OWNER moshiva;
CREATE DATABASE org2 OWNER moshiva;

При необходимости создай еще одного пользователя и раздай привилегии.
Префиксы делать не надо.

Да какой пользователь 10000 тыщ записей способен прочитать??
Сделай поисковые атрибуты по Name там... еще где то.
И показывай первые 100 штук.

Забыл сделать 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 и бенчмарк. Без этого вы будете неубедительны.