Как сгруппировать данные запроса на основе внешних данных?

Question

[Алексей Николаев]

Доброго дня.
Есть таблица со списком ID юзеров (кроме ID там ничего нет, таблица связующая). При выборке эти айдишники выдаются. Но, у одного юзера может быть несколько ID (так устроена система). В таблице никак не отражено (и не может быть отражено), что у такого-то ID есть алиасы, поэтому я могу только передать все связи между ID на этапе построения запроса.

Собственно, цель: нужно получить агрегированное по полю значение из таблицы на основе переданных скалярных значений.

Грубо говоря, в таблице есть юзеры 123, 456, 789. Как составить запрос так, чтобы, явно передав в запросе значения 123 и 789 получить агрегацию по полю, например, users.count для этих двух строк? Что-то вроде GROUP_BY (users.id = 123 OR users.id = 789).

Буду благодарен за наводку на решение. Иными средствами решить, увы, нельзя, система очень костыльная - гребем, как можем.

Answer 1

[galaxy]

Сложно предложить хорошее решение, не видя запроса, но, допустим, можно сконструировать промежуточную таблицу через values. Т.е. что-то типа такого:

SELECT ...
  FROM table1 JOIN table2 ...
  JOIN (
    VALUES (123, ARRAY[123, 789]),
           (345, ARRAY[345])
  ) t (id, aliases) ON (table1.userid = ANY(t.aliases))
 ...

Рабочий (вроде) пример:

SELECT t.id, string_agg(tt.data, ',')
  FROM 
  (
    VALUES (123, 'a'),
           (123, 'aa'),
           (789, 'b'),
           (345, 'c'),
           (345, 'd')
  ) tt (userid, data)
  JOIN
  (
    VALUES (123, ARRAY[123, 789]),
           (345, ARRAY[345])
  ) t (id, aliases) ON (tt.userid = ANY(t.aliases))
 GROUP by t.id

Answer 2

[Vitsliputsli]

Но, у одного юзера может быть несколько ID (так устроена система).

Значит это не id юзера. Сделайте реальное id юзера и указывайте его в ваших алиасах. Далее группируйте по реальному id юзера. Либо сделайте таблицу соответствия и группируйте через нее.

Что-то вроде GROUP_BY (users.id = 123 OR users.id = 789).

Это хардкод. Если сейчас вы и решите текущую задачу таким образом, далее будут большие проблемы из-за подобного подхода.

Comments

[Алексей Николаев]

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

[Vitsliputsli]

Алексей Николаев,

Там никогда не используется реальное ID, потому что ID зависит от контекста использования (какая интеграция и с каким сервисом)

Но это же не мешает вам сделать id однозначно идентифицирующий пользователя, а все остальные привязывать к нему, пусть и через отдельную таблицу связей.

И поверьте, этот хардкод будет одной из наименьших проблем в проекте - мы даже не знаем, с чего начинать рефакторинг, а надо и фичи пилить )

бывает, как вариант пилить фичи и в рамках этих фичей проводить рефакторинг, т.е. улучшать понемногу, и те вещи, которых касается задача.
Но вам действительно виднее, советовать не видя код не слишком правильно.