Реализация «групп»

Первый вариант вполне валиден, если тебе не нужно выбирать юзеров состоящих в группах, а только нужно знать группы конкретного юзера. Второй вариант не годится ни при каких раскладах.

Вариант 3: табличка с парами user_id и group_id.

если тебе не нужно выбирать юзеров состоящих в группах

а в чем проблема?

Но классический вариант таки m2m

а в чем проблема?

Медленно же.

Индексы то можно строить. Запрос даже прикольней выглядит

session.query(User).filter(User.groups.contains(['admin'])).all()

Array скорее хренов тем, что информацию о группах то всё равно придется где-то хранить. И такая операция как удаление группы или переименование станет не такой простой.

Индексировать массивы без веской причины — так себе идея. Да и табличка с парами будет быстрее в любом случае.

Но если это не нужно, я бы ради простоты предпочёл иметь массив групп.

С джойном запрос будет выглядеть не хуже. Ну и мб ORM там вовсе не нужен. Плюс выглядеть он может сильно хуже алхимии в зависимости от языка.

все чушь. тебе нужна таблица соответствия и два справочника. таблица соответствия вида id, gid, uid, etc...

Так чем это не второй вариант?

Таблица groupxusers / usergroup / etc, где будет id,iduser,idgroup
Почему? Потому что в в.1 как ты будешь выбирать всех юзеров по группе? В в.2 как ты будешь выбирать все группы юзера?
/thread

А потом тебе захочется чтобы группа могла состоять не только из юзеров, но еще и из групп.

1) select uid from users where <group_id> = ANY(groups)

2) select gid from groups where <user_id> = ANY(users)

В чём проблема-то?

Допустим, хотим добавить флаг «активности» группе, и выбрать только активные. Как это будет выгядеть?

Откуда это требование вообще появилось?

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

В таблице `users` есть массив `groups[]`,

Head shot.

В таблице `groups` есть массив `users[]`, в котором перечислены члены группы;

Double kill....

Про оптимизацию, надо полагать, ты никогда не слышал?

А потом тебе захочется чтобы группа могла состоять не только из юзеров, но еще и из групп.

Или группы в виде дерева. Уже представил как он будет удалять одну из групп в середине со своими массивами.

В том, что у тебя всегда будет перебираться вся таблица на каждый запрос. И давай, теперь придумай, как выбрать всех юзеров у которых группа есть с каким-нибудь атрибутом, типа «разработчик» (куда входят программисты, тестировщики, девопсы, etc)

Откуда это требование вообще появилось

Вот отсюда:

Есть абстрактный веб-сервис

У тебя сложности?

А битовые маски не предлагают. Наверное не по фэн-шую, но я обычно одним целым полем у пользователей обхожусь. Вставил бит, снял бит, сравнил с маской. Легко и просто. Если каких-то очень сложных вложенностей не планируется.

Те же самые проблемы, что и с массивом. Выбор всех пользователей группы будет перебирать всю таблицу + расширение сущностей. Ну, если их 10-50, то какая разница, конечно.

Зачем такой гемор? 5 табличек юзерс, групс, юзерсгрупс, пермишнс, групспермишнс. Все. Хоть обджойнься

Колво битов конечно - упрешься в лимит обкакаешься

Колво битов конечно

) То, что ими надо сортировать, обычно, еще раньше конечно.

Строго говоря в рабочем варианте это используется только для эмуляции RowLevelSecurity в PostgreSQL 9.4 (в котором еще не было встроенного). Везде где можно - настоящие Postgres пользователи и их Postgress группы. А для RLS - битовые маски на пользователей и их записи. И доступ не к таблицам, а к представлениям, с маской.

Ну, и в нерабочем баловстве в интернетах так делаю, когда уверен, что биты не кончатся раньше.

Спасибо, поговорил )

Это если речь только о пользователях. А вот например фильтры товаров битовыми масками не наделаешь. Тщем, ограничение чревато и у пользаков. А то что для бизнес логики «продукта» используются пользаки и группы БД — тоже не хорошо. Я не спорю что удобно, но не хорошо. Мух от котлет отделять все же надо.

В таблице X есть массив Y

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

Мух от котлет отделять все же надо.

Наверное у нас разные представления о мухах и котлетах )

Приложение полностью написанное на PostgreSQL, использующее все доступные и необходимые возможности этой СУБД, в том числе по пользователям/группам - это котлета. Легко переносимая, независящая от внешнего мира.

А интерфейс пользователя и прокладка между СУБД и интерфейсом - это мухи, которые могут меняться по цвету и вкусу.

Как-то так рассуждал.

Пользователи и группы - это связь many2many. Такая связь делается через промежуточную таблицу. Теоретически, можно сделать и через массивы. Но, во-первых, ты не сможешь построить unique constraint, что один пользователь принадлежит одной группе только один раз, во-вторых, индексировать массив можно, но лучше не нужно.

Я говорю — удобно. Однако это не котлета, а муха. Но на вкус и цвет фломастеры разные, поэтому останемся каждый на своём.