Отображение строк в отношения - PullRequest
Новая
       22

Отображение строк в отношения

2 голосов
/ 23 июня 2019

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

  • has:tasks-update,tasks-access - пользователи с правами доступа tasks-update и tasks-access.
  • role:administrator - пользователи с ролью администратора.

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

У меня уже есть индексы в соответствующих столбцах для ускорения поиска.

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

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

Ответы [ 3 ]

1 голос
/ 01 июля 2019

Хранение списка чего-либо в виде строки в единственном столбце может привести к всевозможным проблемам в дальнейшем

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

Стоит отметить, что любые индексы в этом столбце, скорее всего, НЕ будут использоваться механизмом для этих задач, так как индексы в столбцах на основе строк (другиечем FULL TEXT) действительно полезны только при поиске начала строки

Например, 

SELECT * 
  FROM site_user 
 WHERE recipients LIKE '%tasks-update%'

Не удастся использовать индекс для столбца получателей

Предложение

Я бы разделил ваши текущие списки на новые таблицы, например

  1. role - id, name,…
    • например {3, 'администратор',…}
  2. permission - идентификатор, имя,…
    • например {5, 'tasks-access',…}
    • например, {9, 'tasks-update',…}
  3. site_user - идентификатор, имя, role_id,…
    • например, {7, 'Jeff', 3,…}
  4. site_user_permission - id, site_user_id, license_id,…
    • например, {1, 7, 5,…}
    • например {2, 7, 9,…}

Где из примеров записей «Джефф» является «администратором» и ему назначены «задачи»-update 'и разрешения' tasks-access '

Поиск должен быть легко достижим с помощью JOIN и оставаться согласованным при добавлении или удалении данных.Целостность данных можно поддерживать, добавляя соответствующие внешние ключи и уникальные индексы

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

0 голосов
/ 28 июня 2019

Вам обязательно нужна таблица отношений между пользователями и задачами, и, конечно, в этом отношении вы также должны указать, является ли пользователь администратором или нет. Это лучший способ для разработки структуры вашего приложения вместо объединения информации в один столбец, что вызывает проблему производительности / сложности. Идите вперед с этим подходом, ваша работа выиграет от этого.

0 голосов
/ 23 июня 2019

Испытанный и хороший подход, соответствующий нормальным формам , будет иметь таблицы task_type и role.У вас, конечно, есть пользовательская таблица, и, поскольку у пользователя может быть много ролей и привилегий, вам понадобятся таблица user_role и user_privilege для обработки отношений «многие ко многим».Простой способ решения проблем состоит в том, чтобы иметь некоторые числа, представляющие некоторые привилегии и роли, например, 1 для администратора и 2, 3, 5, 7, 11, 13, 17 и т. Д. Для других привилегий.Наличие аналогичного номера для роли в качестве первичного ключа облегчит проблему сопоставления ролей.Например, давайте рассмотрим случай, когда у вас есть привилегия с кодом 7. Если вы выполняете поиск ролей с идентификатором, кратным этому коду, то вы получите 7 (например, data_read) и 1 (администратор).

...