Архитектура SQL для обработки компетенций сотрудников

Question

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

У меня есть стол с сотрудниками

Table: employee
id, name
1 - John
2 - Jane
3 - Obama
4 - Donald

... ничего особенного. И еще есть таблица компетенций (классификатор специальных задач / обязанностей)

competencies table:
id, name
1 - Janitor
2 - Sysadmin
3 - Programmer
4 - Pilot
...

Каждый сотрудник может иметь несколько компетенций (таблица отношений)

таблица: сотрудник_компетентность

id, employee_id, competency_id
1 - 1 - 1  - John is a Janitor
2 - 1 - 2  - John is also a Sysadmin (imagine that)
3 - 2 - 3  - Jane is a Programmer
4 - 3 - 3  - Obama is a Programmer
5 - 3 - 4  - ...and a Pilot
6 - 4 - 1  - Donald is a Janitor

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

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

2. В коде я хочу иметь возможность выбирать сотрудников с определенной компетенцией (например, перечислить всех сотрудников, которые являются пилотами) ....

Путем жесткого кодирования идентификатора компетенции при перечислении сотрудников я теряю способность свободно определять компетенции. Я мог бы определить пользовательские поля в таблице сотрудников, такие как is_janitor, is_sysadmin, is_programmer, is_pilot и т. Д. ... но тогда я теряю возможность определять неограниченное количество компетенций ...

Есть ли способ решить эту довольно XY-проблему другим подходом к архитектуре БД?

Answer 1

Чтобы выбрать всех программистов из базы данных, используйте, например:

SELECT
 e.name AS empl_name,
 c.name AS comp_name
FROM 
  employee_competency ec,
  competencies c,
  employee e
WHERE
  c.id=ec.competency_id
AND
  e.id=ec.employee_id
AND
  c.id=3

Answer 2

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

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