Лучший дизайн базы данных? - PullRequest
1 голос
/ 28 июня 2011

У нас есть роли, такие как «Владелец», «Редактор», «Просмотр» и т. Д. ... И у каждой роли есть разные привилегии, такие как загрузка, обмен, редактирование, просмотр и т. Д. *

. Я создал две базы данных для этой функции.Какой дизайн базы данных мне нужно реализовать?

1) Table   -> Roles 
   Columns -> Id
              Name
              isDownload
              isShare
              isView

2) Table   -> Roles
   Column  -> Id
              Name
              Description

   Table   -> Privileges
   Column  -> Id 
              Name
              Description

   Table   -> RolesPrivileges
   Column  -> Id
              RoleId
              PrivilegeId

Каковы преимущества и недостатки этих проектов?Какой из них мне нужно реализовать?Что является более масштабируемым и обслуживаемым?Зачем ?

Ответы [ 5 ]

2 голосов
/ 28 июня 2011

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

1 голос
/ 28 июня 2011

Подобные вещи во многом зависят от того, как будет использоваться ваша база данных - такие факторы, как:

  1. Гибкость - возможно, вам понадобится добавить дополнительные роли / привилегии в будущем? Если это так, перейдите к более широкой и гибкой структуре таблицы в # 2.
  2. Сложность - если ваша база данных больше, чем обычная крошечная система, я бы рекомендовал перейти на №2. Однако, если он очень мал и неформально используется, он может стоить вашего сэкономленного времени, чтобы перейти на более простую систему.
  3. Производительность - # 2, очевидно, немного сложнее и, вероятно, потребует больше запросов, особенно если у вас есть случаи, когда вам, возможно, придется делать много одновременно. Тем не менее, это может быть хорошо смягчено путем правильного использования индексации базы данных.
0 голосов
/ 28 июня 2011

Конечно, первый способ это сделать:

Table   -> Roles 
Columns -> Id
           Name
           isDownload
           isShare
           isView
  • простой дизайн
  • вы можете читать роли и привилегии из одной и той же таблицы без необходимости присоединения
  • требует меньше места, чем вторая альтернатива

Однако, если у вас есть динамические привилегии с привилегиями, которые часто добавляются или удаляются, вы можете подумать о подходе 2. Но в противном случае сохранение одной таблицы - это нормально.

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

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

Сначала пример

(liability_mask INT)

def Roles

    RESPONSIBILITES = [ :switchboard, :content_manager, :network_administrator, :financial_manager, :receives_contact_emails ]

    def responsibilites=(responsibilites)
        self.responsible_mask = ([*responsibilites].map(&:to_sym) & RESPONSIBILITES).map { |r| 2**RESPONSIBILITES.index(r) }.sum
    end

    def responsibilites
        RESPONSIBILITES.reject { |r| ((responsible_mask || 0) & 2**RESPONSIBILITES.index(r)).zero? }
    end

    def responsibilites_symbols
        responsibilites.map(&:to_sym)
    end

    def responsible?(responsibility="none")
        responsibilities_symbols.includes?(responsibility.to_sym)
    end
end

Легко добавить большеобязанности в любое время.

А теперь почему?

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

Это также делает запросы SQL более сложными, добавляя еще одно объединение.Помедленнее.Труднее в отладке.

Трудно помнить, что нужно создавать эту таблицу статических данных при развертывании на другом сервере.

0 голосов
/ 28 июня 2011
1) Table   -> Roles 
   Columns -> Id
              Name
              Description
              isDownload
              isShare
              isView


2) Table   -> UserRolesPrivileges
   Column  -> Id
              RoleId
              UserId

UserId происходит из таблицы регистрации пользователей.

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

Я не вижу никакого использования таблиц привилегий, пока пользователь связан с ролями

...