Size: a a a

pgsql – PostgreSQL

2021 February 26

DK

Dmitry Kudryavtsev in pgsql – PostgreSQL
Dmitriy
Везде, где вы обращаетесь к столбцу/таблице с camelCase, нужно двойные кавычки указывать. Но, опять-таки из-за этого удобней under_score - тогда можно не заморачиваться. Только если вы таблицу не назовёте как-нибудь зарезервированным словом.
вот у @Column есть возможность менять имя, а у @ManyToOne что-то нет
источник

DK

Dmitry Kudryavtsev in pgsql – PostgreSQL
в гугле советуют не использовать наследование таблиц, и вроде через @joinColumn можно переименовать
источник

D

Dmitriy in pgsql – PostgreSQL
Dmitry Kudryavtsev
вот у @Column есть возможность менять имя, а у @ManyToOne что-то нет
Всё можно, вот пример (но это уже оффтоп, так что обращайтесь к jsникам):
@Index()
@Column('integer', { name: 'post_id', nullable: true })
postId: number | null;

@ManyToOne(
 () => Post,
 postsPost => postsPost.postsViews,
)
@JoinColumn([{ name: 'post_id', referencedColumnName: 'id' }])
post: Post;
источник

DK

Dmitry Kudryavtsev in pgsql – PostgreSQL
Dmitriy
Всё можно, вот пример (но это уже оффтоп, так что обращайтесь к jsникам):
@Index()
@Column('integer', { name: 'post_id', nullable: true })
postId: number | null;

@ManyToOne(
 () => Post,
 postsPost => postsPost.postsViews,
)
@JoinColumn([{ name: 'post_id', referencedColumnName: 'id' }])
post: Post;
вот , я тоже только это нашел, спасибо)
источник

D

Dmitriy in pgsql – PostgreSQL
Dmitry Kudryavtsev
в гугле советуют не использовать наследование таблиц, и вроде через @joinColumn можно переименовать
Наследование точно не надо, это потом невозможно поддерживать. Даже если столбцы дублируются в куче таблиц - это не повод юзать наследование.
источник

DK

Dmitry Kudryavtsev in pgsql – PostgreSQL
Dmitriy
Наследование точно не надо, это потом невозможно поддерживать. Даже если столбцы дублируются в куче таблиц - это не повод юзать наследование.
а как тогда лучше организовать, вот у меня в сервисе должна фигурировать специализация. Просто 2 независимые таблицы задать?
источник

D

Dmitriy in pgsql – PostgreSQL
Dmitry Kudryavtsev
а как тогда лучше организовать, вот у меня в сервисе должна фигурировать специализация. Просто 2 независимые таблицы задать?
Специализация чего? Это вы всё довольно поверхностно описали, так не ответить на вопрос
источник

D

Dmitriy in pgsql – PostgreSQL
В любом случае просто делайте плоскую структуру Entity-классов (без наследования) со связями между ними, как таблички в БД.
источник

DK

Dmitry Kudryavtsev in pgsql – PostgreSQL
Dmitriy
Специализация чего? Это вы всё довольно поверхностно описали, так не ответить на вопрос
Сервис - услуга. Специализация - область этой услуги. Например замена смесителя  - услуга, специализция - сантехника.  (Не я делал такую таблицу 😁) мне нужно просто реализовать
источник

RT

Ruslan Tanas in pgsql – PostgreSQL
Народ, как правильно заинсертить из sql файла данные в таблицу если часть этих данных уже есть в другой таблице и мне их нужно подставить в id
например interst into table (id, name, var_column) values (1, 'string', select id from table2 where blablabla)
источник

D

Dmitriy in pgsql – PostgreSQL
Ruslan Tanas
Народ, как правильно заинсертить из sql файла данные в таблицу если часть этих данных уже есть в другой таблице и мне их нужно подставить в id
например interst into table (id, name, var_column) values (1, 'string', select id from table2 where blablabla)
Да. Ещё можно уникальный индекс повесить, и вставку делать с ON CONFLICT
источник

D

Dmitriy in pgsql – PostgreSQL
Dmitry Kudryavtsev
Сервис - услуга. Специализация - область этой услуги. Например замена смесителя  - услуга, специализция - сантехника.  (Не я делал такую таблицу 😁) мне нужно просто реализовать
Общие данные можно вынести в одну таблицу, а какие-то таблицы детализации - в отдельные. И связать с первой внешними ключами (с ON DELETE CASCADE). В первой таблице можно создать поле "service_type", чтобы на уровне кода понимать, с какой таблицей джойнить для получения детализации
источник

R

Roman in pgsql – PostgreSQL
Yaroslav Schekin
> Видимо это просто так работает и либо стоит смириться

С чем "смириться", о чём Вы?!

> либо не использовать реляционки для этих целей.

Извните, но я один не понимаю, как Вам удалось сделать этот "вывод"?! ;(
Смириться, что запрос такого характера будет давить цпу на полную.
источник

DK

Dmitry Kudryavtsev in pgsql – PostgreSQL
Dmitriy
Общие данные можно вынести в одну таблицу, а какие-то таблицы детализации - в отдельные. И связать с первой внешними ключами (с ON DELETE CASCADE). В первой таблице можно создать поле "service_type", чтобы на уровне кода понимать, с какой таблицей джойнить для получения детализации
у меня получается как раз и используется связь по внешнему ключу?
источник

D

Dmitriy in pgsql – PostgreSQL
Dmitry Kudryavtsev
у меня получается как раз и используется связь по внешнему ключу?
Я не знаю структуру вашей базы) И не в курсе повесили вы/typeORM внешний ключ или нет
источник

D

Dmitriy in pgsql – PostgreSQL
Часто разрабы внешние ключи вообще не юзают (почему-то)
источник

D

Dmitriy in pgsql – PostgreSQL
А удаление из связанных таблиц делают отдельными запросами в транзакции
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Roman
Смириться, что запрос такого характера будет давить цпу на полную.
И Вы считаете это недостатком потому, что... что?
источник

АК

Алексей Крапивницкий... in pgsql – PostgreSQL
Dmitriy
Часто разрабы внешние ключи вообще не юзают (почему-то)
А какие юзают? ))) Так, для сведения)
источник

R

Roman in pgsql – PostgreSQL
Yaroslav Schekin
> Видимо это просто так работает и либо стоит смириться

С чем "смириться", о чём Вы?!

> либо не использовать реляционки для этих целей.

Извните, но я один не понимаю, как Вам удалось сделать этот "вывод"?! ;(
Возможно я ошибаюсь конечно. Могу показать план запроса. Но лично я в нем не вижу ничего криминального.
источник