Пока все в порядке, это ничего страшного
Но если в базе будут проблемы , то у администратора базы не останется бекдора для исправления проблемы
Если сервис работает под суперпользователем

Мне создать одну роль - service но эта роль не должна иметь свойства superuser?

И все же почему вы против конекта под разными ролями ?

У вас к базе подключается кто ?
Человек ? Или сервис ?

Человек

То есть не
Человек - сервис - база
А именно человек - база ?

Без промежуточной прослойки ?

Ну я запросы делаю сам к базе

Я использую asp mvc. Допустим во view пользователь написал что-то, я передал в контролер и передал в модель

В моделе делаю запрос

Ручками ? Побитово ?
Или все таки с помощью сервиса ?
Из некоторого кода ?

Не путайте людей , кто подключается к базе ?
Человек через ide ?
Или сервис через драйвер ? А за сервисом уже человек

Руками делаю запросы NpgsqlCommand = new NpgsqlCommand(query)

Зачем вам код тогда ? Зачем вам тогда разграничение доступов ?
Ведь вы всегда и все сами делаете ?

Смотрите как я хочу поступить. Я конекчусь под ролью service у этой роли нет привилегии superuser. Далее делаю селект из таблицы user и смотрю какое значение атрибута role у пользователя который авторизовался. Потом делаю реконект под нужной ролью

Так можна ?

Теоретически да,

Правда я совсем не понимаю зачем ..
Это у вас сейчас две роли , а в дальнейшем их становится все больше и больше,
Сналача админ/клиент, потом какой нибудь директор, затем персонал
(которому можно все, но вот это нельзя), потом финансист, следом аналитик и тд и тп

Ну да ладно, раз уж так хочется )

Просто попробую

Будет крайне интересно потом услышать что у вас получится , притом по факту реализации, и спустя некоторое время использования , скажем, например, год

Доброго. Подскажите, каким образом лучше решить следующую задачу по агрегации данных. Ибо на данный момент всё спотыкается о какие-то костыли и работает не совсем так, как ожидается, а про оптимальность и эффективность говорить в принципе пока рано.
Имеется таблица task (20+ полей), но главные для этой задачи — это id (primary key), entities_data (jsonb).
entities_data представляет собой json с определёнными ключами, которых на данный момент 5, но в будущем их будет больше на пару штук. Для примера данные могут быть следующими:
task

id="f0b31453-7bd4-490f-b517-a8fc23d2ff3f", entities_data={"math": "math-1234-9c", "prog": "prog-847-8j", "geo": "geo-8370-8s"}
id="e4ccb5f5-3876-485a-ab2f-2fe5342b350c", entities_data={"phys": "phys-4321-9b", "geo": "geo-812-1k", "nop": "nop-92-5g"}
id="8a7f4365-f50e-48d6-a0c6-d7cd555488a1", entities_data={"math": "math-1202-7f", "prog": "prog-847-8j"}

Соответственно, суть агрегации — объединие всех task, у которых имеются одинаковые пары ключ-значение в entities_data.
Для примера выше, у нас должны быть объеденены первая (id="f0b31453-7bd4-490f-b517-a8fc23d2ff3f") и третья (id="8a7f4365-f50e-48d6-a0c6-d7cd555488a1") задачи (task), поскольку у них одинаковая пара "prog": "prog-847-8j". И результатом такой агрегации я вижу какой-то новый уникальный идентификатор (прим. uuid4), который станет значением поля in_relation в таблице task.
Так если данные выше будут после агрегации в виде:

id="f0b31453-7bd4-490f-b517-a8fc23d2ff3f", entities_data={"math": "math-1234-9c", "prog": "prog-847-8j", "geo": "geo-8370-8s"}, in_relation="5607fc92-f01c-4109-a4ee-2774c1eec0fb"
id="e4ccb5f5-3876-485a-ab2f-2fe5342b350c", entities_data={"phys": "phys-4321-9b", "geo-812-1k", "nop": "nop-92-5g"}, in_relation="8dd6cd71-51a2-47db-a228-29e87de28cb0"
id="8a7f4365-f50e-48d6-a0c6-d7cd555488a1", entities_data={"math": "math-1202-7f", "prog": "prog-847-8j"}, in_relation="5607fc92-f01c-4109-a4ee-2774c1eec0fb"

Количество записей в таблице task ~1 млн, с течением времени будут, естественно, увеличиваться. Предполагаю ответ на следующий вопрос, но может я ошибаюсь и вы сможете внести ясность.
Возможно ли при добавлении новой записи в таблицу task получить за короткий промежуток времени (<1-5 секунд) идентификатор in_relation, который определяет, с какими другими задачами связана новая задача. Учту, что новые записи могут добавляться параллельно с разных клиентов.

Не хочу описывать подробно реализацию, в которой всё было сделано топорно, да и в тоже время она работает медленно и в одном потоке и при этом делает невозможной работу других сервисов, поскольку другие сервисы могут делать update некоторых полей из task, а поскольку происходит блокировка, то всё это дело смотрится вообще страшно.
В мониторинге блокировок было видно, что одна транзакция была заблокирована 10 другими, да и в конечном счёте всё повисло.
Суть реализации была вкратце следующей: для новой задачи получал её entities_data, искал по значению связана ли эта запись с какими либо из имеющимися (была доп. таблица с полями entities_id (primary), entities_name, relation_id (foreign)):
1) Если нет, то просто создавал новый uuid4 и закреплял за этим идентификатором все пары ключ-значение.
2) В случае, если в базе уже была 1 запись, то получал её relation_id и присваивал его к другим парам ключ-значение для новой записи.
3) Если было несколько relation_id, то создавал новый, присваивал его к парам ключ-значение для новой записи, и обновлял все записи, у которых был ранее relation_id новым идентификатором.
Я осознаю насколько это плохое решение, но тем не менее начал именно с него.

После пересмотра схемы, было решено вынести в отдельную таблицу пары из entities_data с привязкой к task.id
В результате чего пример выше был дополнен новой таблицей task_entities (id primary key, name, task_id primary key, foreign key):

id="math-1234-9c", name="math", task_id="f0b31453-7bd4-490f-b517-a8fc23d2ff3f"
id="prog-847-8j", name="prog", task_id="f0b31453-7bd4-490f-b517-a8fc23d2ff3f"
id="geo-8370-8s", name="geo", task_id="f0b31453-7bd4-490f-b517-a8fc23d2ff3f"
id="phys-4321-9b", name="phys", task_id="e4ccb5f5-3876-485a-ab2f-2fe5342b350c"
id="geo-812-1k", name="geo", task_id="e4ccb5f5-3876-485a-ab2f-2fe5342b350c"
id="nop-92-5g", name="nop", task_id="e4ccb5f5-3876-485a-ab2f-2fe5342b350c"
id="math-1202-7f", name="math", task_id="8a7f4365-f50e-48d6-a0c6-d7cd555488a1"
id="prog-847-8j", name="prog", task_id="8a7f4365-f50e-48d6-a0c6-d7cd555488a1"

Теперь entities в явном виде связаны с определённой задачей.
Но я не могу сообразить как можно/нужно поступить с агрегацией теперь. Ибо все мысли так или иначе приводят к решению первым вариантом.
Я пытался сделать агрегацию средствами Postgres'a, но получилось лишь частично. Делал array_agg всех task_id, у которых были равны лишь значения ключей из поля entities_data, но это вроде бы не совсем то, что должно получится, а как соединить вообще все пары из entities_data, когда связаны лишь несколько из них не имею пока понятия.
Надеюсь получилось донести свои мысли.
Были мысли по поводу того, что, поскольку агрегация миллиона записей логически не может быть совершена в течение пары секунд (т.е. каждый раз при добавлении новой записи в task), то необходимо изменить подход для составления агрегации: сделать сервис, который каждые 5-10-20-30 минут будет запускать операцию агрегации (sql запрос postgres'a) на всех имеющихся в таблице данных.
Соответственно, для новой задачи будет указана связь с другими записями через 5-10-20-30 минут в худшем случае, если предыдущая операция агрегации была произведена прямо до добавления записи в таблицу.

тут не любят картинки, будьте добры дублировать текстом