Size: a a a

pgsql – PostgreSQL

2020 June 18

O

Oleh in pgsql – PostgreSQL
всем привет. подскажите как настроить updatedAt. чтобы при любом обновлении - также обновлялось время

в mysql это было бы так
createdAt timestamp default CURRENT_TIMESTAMP not null,
updatedAt timestamp default CURRENT_TIMESTAMP not null on update CURRENT_TIMESTAMP,
источник

KK

Konstantin K in pgsql – PostgreSQL
Yaroslav Schekin
Может, дело совсем не в этом? Вы это где запускаете, hint там нет в сообщении об ошибке?
а, есть хинт :) создать уникальный индекс
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Alex Povar
Приветы!

У меня есть вопрос, который несколько выходит за пределы моих точных познаний по проектированию баз данных.

Собственно, кейс такой.
Проектируется кусок REST API, который позволяет пользователю заполнить огромных размеров форму, состоящую из некоторого фиксированного количества разделов (пусть будет 6).
В каждом разделе пользователь может ввести один из двух типов данных (он прям вот галочкой явно переключается): либо целевые данные (пусть будет информация о страховке, которую он хотел бы оформить) с кучей полей, либо стандартный набор данных о уже существующей страховке (когда и кем выдана).

Соответственно разделов таких фиксированное количество (6), и в дальнейшем нет планов ни по увеличению их количества, ни по возможности динамически добавлять новые разделы.
Для каждого раздела набор целевых данных отличается, а стандартный набор данных - наоборот для всех разделово одинаков.

Итого, на языке сущностей, у меня получается:
- есть некоторая центральная сущность, назовём её InsuranceDetails.
- есть 6 разных сущностей, представляющих целевые данные: MedicalInsuranceDetails, CarInsuranceDetails, HouseInsuranceDetails, итд. У них явно связь 1:1 c InsuranceDetails, и на стороне InsuranceDetails просто лежит FK указывающий на PK каждой из этих таблиц.
- и есть 1 сущность, которая представляет стандартные данные: ExistedInsuranceDetails

И вот мы подобрались к самому главному. А ExistedInsuranceDetails к InsuranceDetails как относится?
С одной стороны это 1:M, потому что один InsuranceDetails может иметь много ExistedInsuranceDetails.
C другой стороны, это 1:1, потому что один InsuranceDetails может иметь 0 или 1 ExistedInsuranceDetails, относящихся к разделу Medical, 0 или 1 ExistedInsuranceDetails относящихся к разделу Car итд.


Т.е. получается какая-то 1:M, но каждая связь тегированна уникально... в общем я даже не догадываюсь как это правильно погуглить 🙂

Сейчас решил это тем, что затащил вообще все FK в InsuranceDetails фактически гвоздями прибив 1:M везде. Есть сомнения в правильности такого подхода в целом, но тут на чаще весов "за", то что местный ORM такое переваривает очень хорошо и не требует дополнительных телодвижений, на чаще весов "против" - сомнения, что это всё вообще правильно.

Вопрос: есть какой-то "правильный" подход для решения подобного класса задач?
> У них явно связь 1:1 c InsuranceDetails, и на стороне InsuranceDetails просто лежит FK указывающий на PK каждой из этих таблиц.

Где Вы такое нашли в реляционном проектировании? ;) Т.е. нормализация Вам бы такой структуры не дала. Т.е. это просто для удобства?

> Сейчас решил это тем, что затащил вообще все FK в InsuranceDetails фактически гвоздями прибив 1:M везде.

Вот и показали бы схему (\d каждой таблицы), а то как-то непонятно, IMHO...
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Oleh
всем привет. подскажите как настроить updatedAt. чтобы при любом обновлении - также обновлялось время

в mysql это было бы так
createdAt timestamp default CURRENT_TIMESTAMP not null,
updatedAt timestamp default CURRENT_TIMESTAMP not null on update CURRENT_TIMESTAMP,
Поле "updated_at timestamptz" + trigger (BEFORE update).
источник

O

Oleh in pgsql – PostgreSQL
Yaroslav Schekin
Поле "updated_at timestamptz" + trigger (BEFORE update).
понял, спасибо
источник

AP

Alex Povar in pgsql – PostgreSQL
Yaroslav Schekin
> У них явно связь 1:1 c InsuranceDetails, и на стороне InsuranceDetails просто лежит FK указывающий на PK каждой из этих таблиц.

Где Вы такое нашли в реляционном проектировании? ;) Т.е. нормализация Вам бы такой структуры не дала. Т.е. это просто для удобства?

> Сейчас решил это тем, что затащил вообще все FK в InsuranceDetails фактически гвоздями прибив 1:M везде.

Вот и показали бы схему (\d каждой таблицы), а то как-то непонятно, IMHO...
> Где Вы такое нашли в реляционном проектировании? 😉 Т.е. нормализация Вам бы такой структуры не дала. Т.е. это просто для удобства?

Ну, там еще есть пачка check constraint-ов, которые проверяют некоторые соотношения. Поэтому так.
Не думал, что это будет сильно удивительной частью, потому что эта часть задумывалась как подводка к главному вопросу )
источник

A

Alex in pgsql – PostgreSQL
Господа, кто-то использует связку haproxy + pgbouncer ? Интересует, как получить реальный ip клиента в логах на pgbouncer, а не  ip haproxy
источник

O

Oleh in pgsql – PostgreSQL
Yaroslav Schekin
Поле "updated_at timestamptz" + trigger (BEFORE update).
хорошо что отметил updated_at, а то с updatedAt не работает триггер (верхний регистр не пашет)
источник

AP

Alex Povar in pgsql – PostgreSQL
Владимир Яворский
не знаю кому как, но мне лень читать портянку(
Раз портянка выглядит страшно, попробую сжать:

одна таблица несколькими разными полями ссылается на другую таблицу.
Как это сделать правильно?

Дальше - примеры.

Например, один InsuranceDetails может иметь ссылки на две ExistedInsuranceDetails. Можно вот так попробовать:
CREATE TABLE insurance_details (
 id SERIAL,
 ... more fields,
 medical_existed_insurance_details INT,
 car_existed_insurance_details INT,
 PRIMARY KEY (id),
 CONSTRAINT fk_med_default FOREIGN KEY (medical_existed_insurance_details) REFERENCES existed_insurance_details (id),
 CONSTRAINT fk_car_default FOREIGN KEY (car_existed_insurance_details) REFERENCES existed_insurance_details (id)
);

CREATE TABLE existed_insurance_details (
 id SERIAL,
 ... more fields,
 PRIMARY KEY (id)
);


А можно вот так:

CREATE TABLE insurance_details (
 id SERIAL,
 ... more fields
 PRIMARY KEY (id)
);

CREATE TABLE existed_insurance_details (
 id SERIAL,
 ...more fields,
 insurance_details_id INT,
 type_id INT,
 PRIMARY KEY (id),
 CONSTRAINT ... FOREIGN KEY (insurance_details_id) REFERENCES insurance_details (id),
 CONSTRAINT ... FOREIGN KEY (type_id) REFERENCES existed_insurance_detail_types (id),
 UNIQUE (insurance_details_id, type_id)
);

CREATE TABLE existed_insurance_detail_types (
 id SERIAL,
 name TEXT
);

INSERT INTO existed_insurance_detail_types
VALUES (1, 'CAR'), (2, 'MEDICAL');
источник

П

Павел П. in pgsql – PostgreSQL
Подскажите пожалуйста, где (кроме исходников) можно почитать про то, как работает pg_basebackup?

Конкретно интересует такой вопрос: во время клонирования на исходной базе в логе вижу сообщения об этом процессе:
[2020-06-11 13:19:24.423 MSK u=postgres d=[unknown] h=xxx.xxx.xxx.хх(33294) p=56932 l=3 trans_id=0] 

Что за порт 33294, как он выбирается, меняется ли в процессе клонирования..?

Если у меня фаервол закрыл всё входящее-исходящее кроме 5432 и 22 порта, pg_basebackup работать не сможет?
источник

GS

Grigory Smolkin in pgsql – PostgreSQL
Павел П.
Подскажите пожалуйста, где (кроме исходников) можно почитать про то, как работает pg_basebackup?

Конкретно интересует такой вопрос: во время клонирования на исходной базе в логе вижу сообщения об этом процессе:
[2020-06-11 13:19:24.423 MSK u=postgres d=[unknown] h=xxx.xxx.xxx.хх(33294) p=56932 l=3 trans_id=0] 

Что за порт 33294, как он выбирается, меняется ли в процессе клонирования..?

Если у меня фаервол закрыл всё входящее-исходящее кроме 5432 и 22 порта, pg_basebackup работать не сможет?
pg_basebackup работает через 5432
источник

П

Павел П. in pgsql – PostgreSQL
Grigory Smolkin
pg_basebackup работает через 5432
в log_line_prefix стоит h=%r
%r - это Имя удалённого узла или IP-адрес, а также номер порта.
почему порт 33294 а не 5432 ?
источник

GS

Grigory Smolkin in pgsql – PostgreSQL
Павел П.
в log_line_prefix стоит h=%r
%r - это Имя удалённого узла или IP-адрес, а также номер порта.
почему порт 33294 а не 5432 ?
ну это же номер порта на удаленной машине
источник

П

Павел П. in pgsql – PostgreSQL
Grigory Smolkin
ну это же номер порта на удаленной машине
да, про это и вопрос получается. на удаленной машине, на которой запущен pg_basebackup.
как именно был выбран порт 33294, рандомно? А если бы он был занят чем-либо? Вот это интересно узнать.
источник

GS

Grigory Smolkin in pgsql – PostgreSQL
ядро выдало какой свободный был
источник

GS

Grigory Smolkin in pgsql – PostgreSQL
почитайте как TCP/IP устроен
источник

П

Павел П. in pgsql – PostgreSQL
Grigory Smolkin
ядро выдало какой свободный был
как и предполагалось) Спасибо за ответ.
источник

П

Павел П. in pgsql – PostgreSQL
Павел П.
как и предполагалось) Спасибо за ответ.
Хотя неизвестно может ли он меняться в процессе. Проще наверно явно и проверить
источник

2_

2flower _ in pgsql – PostgreSQL
Konstantin K
а, есть хинт :) создать уникальный индекс
так это есть в доке. опять никто читать не хочет. :)
источник

G

Grek in pgsql – PostgreSQL
добрый вечер
когда создавал юзера вроде задавал пароль
а тут в итоге какая то генерация
источник