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
...

每个员工可以具有多种能力（关系表）

表：employee_competency

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

数据库体系结构存在的现实问题或如何处理此类情况。

我希望能够定义无限数量的能力，并且这些能力可能会因一个客户而异（另一个，我正在编程的项目将安装在这里的项目-每个项目安装可以具有一组不同的能力）。< / p>
在代码中，我希望能够选择具有特定能力的员工（例如-列出所有飞行员的员工）。...

通过在列出员工时对能力ID进行硬编码，我失去了自由定义能力的能力。我可以在员工表中定义自定义字段，例如is_janitor，is_sysadmin，is_programmer，is_pilot等...，但随后我失去了定义无限数量的能力的能力...

是否有一种方法可以使用另一种DB体系结构方法来解决此XY问题？

Answer 1

此处的关键思想是您必须具有该列表，该列表还允许您选择由数据驱动的能力。因此，当您在要选择要列出的能力的屏幕/表单/页面上时，可以通过数据库中的能力表来驱动选择，将能力的ID作为选择的值传递回查询这样您就可以按能力查询员工列表。

永远不要将单个ID放入系统中。现在，当您要根据能力进行驾驶时，这变得很复杂。这需要在更高的抽象层次上进行思考。例如，假设您有一个要在其中显示另一个选项卡的表格，以允许客户选择飞行员经过认证的飞机。为了实现这一点，我通常创建一些标志，这些标志实际上定义了要添加到相关表中的驾驶行为（例如CAN_SELECT_PLANES）。该表定义了系统的功能，而不是能力的功能。保持这种抽象很重要，因为客户将希望更改其能力名称，稍后您将发现该功能的新用途。

Answer 2

要从数据库中选择所有程序员，请使用例如：

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

用于处理员工能力的SQL体系结构设计

2 个答案: