в общем классика. есть юзер юзерам надо дать права. раньше была роль одна но надо теперь сделать модель с пермишшенами.

ну ок. всё замечательно. делаем как обычно - т.е. таблица пермишены. и таблица юзер-пермишен. всё гут. всё банально и как у всех.
идем дальше - ой у нас слик. про слик и джойны я тут уже вещал. выглядит как гумно. иначе не делается. вариант создавать сущность:
UserPermissions(user:User, permissions:Seq<Permission>) и делать длинные колбасы с палочками и точками в репозитории для джойнов.
-- наверное сойдет.

НО. а если сделать такую модель вообще без джойнов?

есть сущность юзер. у сущности юзер есть поле енамов: пермишшнз. в базе храним просто поле массив стрингов где эти пермишшены и хранятся типа {auditor, watcher, producer} и т.п.

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

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

Leonid KudryavtsevВопрос в чем?

Храните все в текстовом файле.
Из плюсов:
1. Мы избавляемся от join'ов
2. Мы избавляемся об базы данных. Profit!
Из минусов:
1. Не подумает ли начальство избавиться и от программистов?

p.s. денормализация всегда была и будет. Но для этого и есть программист. что бы принять решение, требует ли его задача нормализацию или, наоборот, будет лучше денормализовать структуру.
да. вот я и не могу решить нужна она или нет в данном случае. и какие от нее будут профиты. и текстовые файлы тоже решение кстати. но не в данном случае. у меня две опции - нормализованно но с "особенностями" слика (надо лопатить много кода), либо денормализованно - кода меньше, но другие нюансы возникают.

PetroNotC SharpandreykaTпричем тут спринг? впросто пример жизненный прдумай
В спинге. security уже решены все отношения.
ничего там не решено. ты вообще в глаза его видел? откуда спринг знает что ты хочешь и как? он тебе только удобный набор конфигурируемых либ даст. а то как ты заюзаешь свои права и где и как - это сам всё делаешь ручками.

ты мне отвечаешь на вопрос которого я не задавал.

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

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

dimonz80andreykaTв общем классика. есть юзер юзерам надо дать права. раньше была роль одна но надо теперь сделать модель с пермишшенами.

ну ок. всё замечательно. делаем как обычно - т.е. таблица пермишены. и таблица юзер-пермишен. всё гут. всё банально и как у всех.
идем дальше - ой у нас слик. про слик и джойны я тут уже вещал. выглядит как гумно. иначе не делается. вариант создавать сущность:
UserPermissions(user:User, permissions:Seq<Permission>) и делать длинные колбасы с палочками и точками в репозитории для джойнов.
-- наверное сойдет.

НО. а если сделать такую модель вообще без джойнов?

есть сущность юзер. у сущности юзер есть поле енамов: пермишшнз. в базе храним просто поле массив стрингов где эти пермишшены и хранятся типа {auditor, watcher, producer} и т.п.

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

От реляций избавляются когда ACL разрастается до ужаса (N юзеров * M пермишнов -> Inf). Тогда да: плоская модель, битовые маски и т/п, но твоя поделка никогда до таких объемов не разрастется.

Если проблема чисто в slick то выкинь его и пользуй anorm какой-нить Вот наример так
Откуда ты знаешь что у меня за поделка и до чего она не разрастается?

Я бы рад чтоб она не разрослась. Но увы она разрастается.

Отличный совет выкинь слик. Я не хочу его выкидывать потому что он уже заюзан и твой анорм тоже не идеален и в нем косяк будет где нибудь в другом месте. Зачем мне это надо?

Слик странненький но ничего лучше под скалу не придумали пока.

PetroNotC Sharpdimonz80От реляций избавляются когда ACL разрастается до ужасатоже вот смотрю. У нас в java прогер напигет 3 раза if и сразу в форум что это некрасиво и нужен паттерн избавления от if.
То есть тема без описания проблемы внятно и указания в теме что Scala.
У меня есть коллега мы с ним одно время работали на одном проекте так вот он раз зафигачил 6 вложенных ифов. С его точки зрения было почти норм. Наверное твой знакомый. С моей это было нет и отправился он искать шаблон от избавления от 6 не следует ифов

dimonz80andreykaTв общем классика. есть юзер юзерам надо дать права. раньше была роль одна но надо теперь сделать модель с пермишшенами.

ну ок. всё замечательно. делаем как обычно - т.е. таблица пермишены. и таблица юзер-пермишен. всё гут. всё банально и как у всех.
идем дальше - ой у нас слик. про слик и джойны я тут уже вещал. выглядит как гумно. иначе не делается. вариант создавать сущность:
UserPermissions(user:User, permissions:Seq<Permission>) и делать длинные колбасы с палочками и точками в репозитории для джойнов.
-- наверное сойдет.

НО. а если сделать такую модель вообще без джойнов?

есть сущность юзер. у сущности юзер есть поле енамов: пермишшнз. в базе храним просто поле массив стрингов где эти пермишшены и хранятся типа {auditor, watcher, producer} и т.п.

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

От реляций избавляются когда ACL разрастается до ужаса (N юзеров * M пермишнов -> Inf). Тогда да: плоская модель, битовые маски и т/п, но твоя поделка никогда до таких объемов не разрастется.

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