|
Задача видимости записей
|
|||
---|---|---|---|
#18+
В БД есть следующие сущности: users(id, name, role) - пользователи системы, role=['manager', 'user'] departments(id, name) - отделы пользователей categories(id, name) - категории работ которые выполняет организация userdepartments(id, user, department) - список отделов каждого пользователя (один пользователь может состоять в разных отделах) usercategories(id, user, category) - список разрешенных категорий работ каждого пользователя (один пользователь может выполнять несколько видов работ) Помогите с проектированием такого функционала: Каждый пользователь с role="manager" может отвечать за несколько видов работ, состоять в нескольких отделах и просматривать списки пользователей этих отделов. Соответственно, в общем случае, он должен видеть список всех пользователей, которые состоят в таких же отделах и тех же категорий работ, как и он. Навскидку, пришло что-то подобное: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
На скрине приведен разбор explain Есть какие замечания, или предложения? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2017, 22:50 |
|
Задача видимости записей
|
|||
---|---|---|---|
#18+
eurobaxСоответственно, в общем случае, он должен видеть список всех пользователей, которые состоят в таких же отделах и тех же категорий работ, как и он. А вы точно хотите ограничить список пользователей??? Обычно задача ограничения доступа применяется к документам "таких же отделов и тех же категорий работ". А пользователей показывают всех, тем более если пользователь переходит из отдела в отдел, что произойдет с его старыми записями? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2017, 20:19 |
|
Задача видимости записей
|
|||
---|---|---|---|
#18+
sereginseregin, С документами как раз все просто. Документ относится к какому-то конкретному подразделению и виду работ, отбор будет простой. А вот с пользоватлями получается пересечение множеств (пользователь может состоять в нескольких подразделениях и иметь допуск к нескольким видам работ), здесь и напрашивается грамотный подход и оптимизация. Если взять ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2017, 00:39 |
|
Задача видимости записей
|
|||
---|---|---|---|
#18+
sereginseregin, Добавлю насчет перехода Пользователя в другой раздел. Это повлияет только на видимость этого пользователя для Менеджера. Т.е. в данном вопросе нам нужно обеспечить, чтобы Менеджер видел только "своих" пользователей. Если пользователь не состоит ни в одном отделе, которые курирует Менеджер, то последний и не должен его видеть. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2017, 00:44 |
|
Задача видимости записей
|
|||
---|---|---|---|
#18+
eurobax, если человека со скиллами танкиста и летчика прикомандировали сразу к двум отделам, это не значит, что он и там и там будет одновременно ездить и летать... Я к тому, что наверное, должны быть не только сущности "Сотрудник в отделе", но и для каждого экземпляра такой сущности должен быть как минимум один экземпляр "Допуск к Работе". Обычная практика. Имхо, если нарисовать картинку - с запросами вопросы исчезнут. Что-нибудь такое: ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2017, 02:35 |
|
Задача видимости записей
|
|||
---|---|---|---|
#18+
Дальше - просто: для конкретного Сотрудника выбираем список пар идентификаторов сущностей Отдел и Работа, где этот Сотрудник допущен к работе в качестве менеджера. И джойним ("по цепочке") юзеров, имеющих допуск к таким работам в этих отделах. Если схема более проста (т.е. такая, как ты описан в начале) - подправь её, и все. :) ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2017, 02:42 |
|
Задача видимости записей
|
|||
---|---|---|---|
#18+
Если рассматривать не взаимодействие экземпляров сущностей, а самих сущностей, то получится простая ER - диаграмма (стрелка в М-Д связи показывает в направлении М): ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2017, 07:46 |
|
Задача видимости записей
|
|||
---|---|---|---|
#18+
Согласен с чччД, "допуск к работам" близок к usercategories, возможно это одно и тоже. Менеджеру по Вашему описанию нужны не пользователи, а доступные категории работ с указанием возможных исполнителей. Пользователи тут как справочник с ФИО и Отделом (для доп. фильтрации). Могу ошибаться. По общему описанию задачи не понятно, зачем это нужно менеджеру. Соответственно цель тоже не ясна. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2017, 09:45 |
|
Задача видимости записей
|
|||
---|---|---|---|
#18+
sereginseregin... По общему описанию задачи не понятно, зачем это нужно менеджеру.Каждый менеджер должен знать подчиненный личный состав. "Каждый солдат должен знать свой маневр" - (с). sereginseregin...Соответственно цель тоже не ясна.Курсовик? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2017, 09:52 |
|
Задача видимости записей
|
|||
---|---|---|---|
#18+
Пример предметной области может быть такой: Автопарк в Удмуртской республике. Departments - это нас.пункты: - Ижевск - Воткинск - Сарапул - Глазов Categories - виды услуг: - такси - пассажирские перевозки (автобусы) - грузоперевозки Газель - грузоперевозки Камаз - спецтехника Менеджеры (каждый закреплен за городами): - начальник пассажирских перевозок (такси, автобусы) - начальник грузоперевозок (Газель, Камаз) - начальник спецтехники - начальник доставки пиццы (шутка) Задачи менеджера (начальника): мониторить все что относится к их сфере работ, в их городах. А это сотрудники, заказы, расчеты с траспортниками (водителями) Водители могут привлекаться на определенные виды работ во всех подразделениях, обычно, территориально близких Например, таксисты - одновременно в Ижевске и Воткинске. Пассажирские перевозки - по направлениям (Ижевск-Воткинск, Ижевск-Глазов) Грузоперевозки, Спецтехника - по всей республике В данной ветке волнует больше вопрос: Допустим, есть начальник Иванов. Отвечает за Ижевск и Воткинск, по сфере работ грузоперевозки. Т.е. если заказ поступил в его городах - он курирует эти заказы, привлекает водил и ведет с ними расчеты. Ему в процессе работы с подчиненным составом не нужны таксисты, не нужна спецтехника, не нужны водители из Сарапула, хотя все это одна организация. Он должен видеть: - состав только своих водителей - только свои заказы - только расчеты по своим водителям ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2017, 00:30 |
|
Задача видимости записей
|
|||
---|---|---|---|
#18+
eurobaxПример предметной области может быть такой: .... Допустим, есть начальник Иванов. Отвечает за Ижевск и Воткинск, по сфере работ грузоперевозки. Т.е. если заказ поступил в его городах - он курирует эти заказы, привлекает водил и ведет с ними расчеты. Ему в процессе работы с подчиненным составом не нужны таксисты, не нужна спецтехника, не нужны водители из Сарапула, хотя все это одна организация. В данном случае я бы не стал сильно завинчиваться на универсальном ограничении фильтрации таксистов по менеджеру. Для выбора таксиста в заявке уже есть город и тип такси, по менеджеру нужна дополнительная фильтрация только по иерархии подчинения. Но опять же вопрос мне кажется некорректен. Ограничивать нужно не список таксистов или их транспорт, а места приписки - а это отдельный документ-сущность в БД зависимая от времени. Если таксист меняет место приписки или тип такси, должна оставаться история, что менеджер мог назначать таксисту данный заказ. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2017, 12:35 |
|
Задача видимости записей
|
|||
---|---|---|---|
#18+
sereginseregin, Место приписки возникает только в самом заказе: в определенном подразделении на определенный вид работ назначается Водитель. Сам водитель может подписаться на разные виды работ, и обслуживать несколько подразделений. Как раз, для этого есть usercategories, userdepartments - определяют сферы работ и место работ, куда водитель готов ездить. Продолжу конкретику, вот пример отбора заказов для Менеджера, когда он просматривает все заказы за которые отвечает: Код: sql 1. 2. 3. 4. 5. 6.
... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2017, 15:25 |
|
Задача видимости записей
|
|||
---|---|---|---|
#18+
Сама модель предусматривает следующее: Водителей (участников) ~ 1000 человек Менеджеров ~ 20 человек Подразделений ~ 20 ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2017, 15:27 |
|
Задача видимости записей
|
|||
---|---|---|---|
#18+
eurobaxsereginseregin, Сам водитель может подписаться на разные виды работ, и обслуживать несколько подразделений. Как раз, для этого есть usercategories, userdepartments - определяют сферы работ и место работ, куда водитель готов ездить. ИМХО. Правильней подписку водителя реализовать как документ-договор, в котором в шапке будет период действия и ссылка на место работы, а в табличной части перечень видов работ. Плюс такой документ можно будет расширять дополнительными условиями договора. В первом SQL менеджер ошибочно получит информацию о водителе, который готов работать в нужном районе, но выполнять нужный вид работ готов только в другом (соседнем) районе. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2017, 21:31 |
|
|
start [/forum/moderation_log.php?user_name=Guest2010]: |
0ms |
get settings: |
11ms |
get forum list: |
16ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
47ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
53ms |
get tp. blocked users: |
2ms |
others: | 666ms |
total: | 844ms |
0 / 0 |