Size: a a a

pgsql – PostgreSQL

2021 March 23

ЕГ

Евгений Ганьшин... in pgsql – PostgreSQL
@zaitsevkv закинь в лс номер банковской карты плиз, скину потом пару сотен
источник

ЕГ

Евгений Ганьшин... in pgsql – PostgreSQL
или нормер телефона, хз как хочешь
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Евгений Ганьшин
таблица из которой считаем доход
Можно без картинок, а? И не нужно обрезать \d — показывайте полностью.

Хмм... что-то эта ORM делает сильно не так (или Вы как-то ей не так пользуетесь).
Во-первых, раз таблица одна, то и данных по пользователям, которых в ней нет, Вы в принципе получить не можете (я про случай, когда пользователь есть, но в этой таблице никаких "движений" по нему нет).
Дальше (я немного отформатировал):
-- Вообще, не стоит использовать ключевые слова, вроде user, как названия таблиц
SELECT "user".firstname || ' ' || "user".lastname AS fullname,
      "user".level,
      COALESCE(SUM(revenues.revenue), 0.00) AS total_revenue,
      COALESCE(SUM(revenues_m.revenue), 0.00) AS this_month_revenue
 FROM "user" AS "user"
 LEFT JOIN revenue AS revenues
   ON revenues."userId" = "user".id
 LEFT JOIN revenue AS revenues_m -- Зачем таблица JOIN-ится второй раз?
                                 -- Можно же отфильтровать в SELECT
   ON revenues_m."userId" = "user".id
WHERE "user"."referrerId" = 2
  AND revenues_m.created_at BETWEEN '2021-02-23'::timestamp AND '2021-03-23'::timestamp
   -- Выше сразу две ошибки --- помещение условия на nullable table из LEFT JOIN
   -- в WHERE (что "превращает" его в INNER); timestamp вместо timestamptz
GROUP BY "user".id;
источник

ЕГ

Евгений Ганьшин... in pgsql – PostgreSQL
-- Вообще, не стоит использовать ключевые слова, вроде user, как названия таблиц


да, я узнал об этом уже когда написал это
источник

KZ

Konstantin Zaitsev in pgsql – PostgreSQL
Евгений Ганьшин
@zaitsevkv закинь в лс номер банковской карты плиз, скину потом пару сотен
э, «спасибо» достаточно
источник

ЕГ

Евгений Ганьшин... in pgsql – PostgreSQL
Konstantin Zaitsev
э, «спасибо» достаточно
спасибо:)
источник

ЕГ

Евгений Ганьшин... in pgsql – PostgreSQL
Yaroslav Schekin
Можно без картинок, а? И не нужно обрезать \d — показывайте полностью.

Хмм... что-то эта ORM делает сильно не так (или Вы как-то ей не так пользуетесь).
Во-первых, раз таблица одна, то и данных по пользователям, которых в ней нет, Вы в принципе получить не можете (я про случай, когда пользователь есть, но в этой таблице никаких "движений" по нему нет).
Дальше (я немного отформатировал):
-- Вообще, не стоит использовать ключевые слова, вроде user, как названия таблиц
SELECT "user".firstname || ' ' || "user".lastname AS fullname,
      "user".level,
      COALESCE(SUM(revenues.revenue), 0.00) AS total_revenue,
      COALESCE(SUM(revenues_m.revenue), 0.00) AS this_month_revenue
 FROM "user" AS "user"
 LEFT JOIN revenue AS revenues
   ON revenues."userId" = "user".id
 LEFT JOIN revenue AS revenues_m -- Зачем таблица JOIN-ится второй раз?
                                 -- Можно же отфильтровать в SELECT
   ON revenues_m."userId" = "user".id
WHERE "user"."referrerId" = 2
  AND revenues_m.created_at BETWEEN '2021-02-23'::timestamp AND '2021-03-23'::timestamp
   -- Выше сразу две ошибки --- помещение условия на nullable table из LEFT JOIN
   -- в WHERE (что "превращает" его в INNER); timestamp вместо timestamptz
GROUP BY "user".id;
тоже спасибо!
источник

Ð

Ð in pgsql – PostgreSQL
Евгений Ганьшин
-- Вообще, не стоит использовать ключевые слова, вроде user, как названия таблиц


да, я узнал об этом уже когда написал это
почему?
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Евгений Ганьшин
-- Вообще, не стоит использовать ключевые слова, вроде user, как названия таблиц


да, я узнал об этом уже когда написал это
Другие ошибки-то исправьте. :)
источник

ЕГ

Евгений Ганьшин... in pgsql – PostgreSQL
потому что потом придется в селекте делать так select "user".something
источник

Ð

Ð in pgsql – PostgreSQL
и че
источник

ЕГ

Евгений Ганьшин... in pgsql – PostgreSQL
не красиво
источник

D

Denisio in pgsql – PostgreSQL
Alexey Stavrov
> ты получишь уже обновлённые записи

Возможно так учат в университетах на примерах двухфазных блокировок, но я на самом деле не знаю, чего там рассказывают)
В PG в RR снимок возьмётся во время первого стейтмента транзакции, а дальше строки будут отдаваться, которые изменены были до этого снимка.
А так в целом правильно написано.
а ты не путаешь с serializable ?
источник

ЕГ

Евгений Ганьшин... in pgsql – PostgreSQL
ну и принятно таблицы называть во множественном числе
источник

Ð

Ð in pgsql – PostgreSQL
это все условности
источник

Ð

Ð in pgsql – PostgreSQL
некоторые наоборот, называют сущность как сущность, как объект который она описывает
источник

Ð

Ð in pgsql – PostgreSQL
и это тоже по-своему лаконично получается.
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Ð
это все условности
Точно! Надо все таблицы называть "Table_1", "Table_2", ... "Table_N", а все поля — "Column_1", "Column_2" ... "Column_N". ;)
Профессиональный программист пишет для коллег, машине "понятно" и так, как я написал выше.
Чем больше мусора (вроде лишних кавычек), тем лично мне (может, не только мне?) труднее читать, например.
источник

Ð

Ð in pgsql – PostgreSQL
Yaroslav Schekin
Точно! Надо все таблицы называть "Table_1", "Table_2", ... "Table_N", а все поля — "Column_1", "Column_2" ... "Column_N". ;)
Профессиональный программист пишет для коллег, машине "понятно" и так, как я написал выше.
Чем больше мусора (вроде лишних кавычек), тем лично мне (может, не только мне?) труднее читать, например.
обфускацию тоже никто не отменял )
источник

VY

Victor Yegorov in pgsql – PostgreSQL
Ð
обфускацию тоже никто не отменял )
обфусцируют данные, а не объекты
источник