PosgreSQL как хранить пользователей

Таблицу. Роли загромоздят СУБД.

Если используется двухзвенная архитектура, нужно использовать пользователей БД, если используется трёхзвенная архитектура, нужно использовать отдельных пользователей.

Двухзвенная - это когда программа сразу работает с базой данных? А трехзвенная - это когда программа обращается к некоторой программе-серверу, а та в свою очередь к БД? А какая архитектура лучше по фэншую?

а если много-звенная, то вообще без пользователей?

Суть твоего вопооса не понял. Смешивать постгресовских пользователей(ROLE) и пользователей твоего приложения можно только в особенных случаях:

1) пользовательский клиент подключается не браузером или через API, а прямо напрямую к БД, и тебе их нужно как-то аутентифицировать. т.е. между кодом у пользователя которому ты не доверяешь и твоей БД отсутствует прослойка. НО, иногда такую прослойку (можно использовать HTTP) имеет смысл всё же добавить (это даст некоторые выгоды), тем самым уйти от решения клиентская программа<->БД

2) суть задачи такова, что требуется доступ к специальным возможностям постгреса не в плане аутентификации, а в плане авторизации. например, например контполь права запуска тех или иных хранимых процедур, или экзотика в виде row-level security. в таких случаях нужно четко осознавать, что задачу можно только таким способом и это даст огромные выгоды. такие случаи редки.

в остальных случаях втягивать постгресовую посистему пользователей не нужно.

Двухзвенная - это когда программа сразу работает с базой данных? А трехзвенная - это когда программа обращается к некоторой программе-серверу, а та в свою очередь к БД?

Да.

А какая архитектура лучше по фэншую?

Трёхзвенная.

Делать в базе таблицу users с пользователями

есть еще вариант сделать рядом БД с пользователями.

Например LDAP :)

и тоже вариант :)

А если потребуется горизонтальный рост? Я не претендую и не хочу оспаривать правильность решения, но как я понимаю сейчас все манипуляции стараются отдать на совесть внутренним механизмам БД, т.к. проще расширение. А тут ещё одну базу веди...

Т.е. по-твоему в качестве пользователей для моей задачи лучше использовать роли postgreSQL ?

Таблицу, как сказал rht

А если потребуется горизонтальный рост?

говорят reOpenLdap это умеет.

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

Интересная штука. Спасибо. Правда в Мегафоне как говорят используется.

Делать в базе таблицу users с пользователями

есть еще вариант сделать рядом БД с пользователями.

предложение идиотское - заводить еще одну БД для таблицы users в условиях, когда уже есть одна БД. в контексте вопроса ТС дико выглядит. видимо для таблицы products будет заведена еще одна БД например mongo, т.е. просто чтобы попонтоваться. и так далее по новой БД для каждой таблицы.

Тебе же уже объяснили, не трогай собственные роли pg, они не для этого. Заведи прослойку и отправляй данные по http. На прослойке аутентифицируй пользователей по таблице users в pg.

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

Табличками конечно же.

юзер <- группа юзеров -> устройство -> значение -> архив значений

Легенда: многие <- один

предложение идиотское

или нет, oauth2 в помощь ;)