为以下简单示例设计架构的最佳方法是什么？

Question

我一直在研究以下数据的不同模式（很多年没有接触过数据库），但 none 看起来很理想。

    A           B           C           D           E
1   Included    Included    Paid        Disabled    Paid
2   Included    Included    Paid        Disabled    Paid
3   N/A         N/A         N/A         Disabled    Paid
4   Included    Included    N/A         Disabled    Paid
5   N/A         N/A         Included    Disabled    Paid

目前有 5 个软件添加到 A-E，但可能会增加，目前还有 5 个设备 1-5，但还会有更多。软件选项包括在内、不适用、付费或禁用（未测试）。

我最初有逻辑确定哪个设备在相关软件中有什么选项，但现在有多个接收器将依赖此信息，所以我想将它存储在数据库中并允许其他软件只提取给定设备类型 (1-5) 的信息。

Answer 1

我建议使用这个

device
--------
+id
 title
 ...

sw_addon
--------
+id          // (PK, CK)
+device_id   // (PK, CK, FK from device table)
+addon_name  // (PK, CK)
 addon_option
 ...

这样的数据

device:
-----------------
| id | title    |
-----------------
|  1 | device 1 |
|  2 | device 2 |
|  3 | device 3 |
|  4 | device 4 |
|  5 | device 5 |
-----------------

sw_addon:
----------------------------------------------
| id | device_id | addon_name | addon_option |
----------------------------------------------
|  1 |         1 | A          | Included     |
|  2 |         1 | B          | Included     |
|  3 |         1 | C          | Paid         |
|  4 |         1 | D          | Disabled     |
|  5 |         1 | E          | Paid         |
|  6 |         2 | A          | Included     |
|  7 |         2 | B          | Included     |
|  8 |         2 | C          | Paid         |
|  9 |         2 | D          | Disabled     |
| 10 |         2 | E          | Paid         |
| 11 |         3 | A          | N/A          |
| 12 |         3 | B          | N/A          |
| 13 |         3 | C          | N/A          |
| 14 |         3 | D          | Disabled     |
| 15 |         3 | E          | Paid         |
| 16 |         4 | A          | Included     |
| 17 |         4 | B          | Included     |
| 18 |         4 | C          | N/A          |
| 19 |         4 | D          | Disabled     |
| 20 |         4 | E          | Paid         |
| 21 |         5 | A          | N/A          |
| 22 |         5 | B          | N/A          |
| 23 |         5 | C          | Included     |
| 24 |         5 | D          | Disabled     |
| 25 |         5 | E          | Paid         |
----------------------------------------------

Answer 2

它是（软件）附加组件和设备之间的多对多关系。多对多关系本身有一个属性 option_value ，它将是一组枚举的 4 个值（包括、不适用、付费或禁用（未测试））。 您也可以将此枚举作为单独的 Option_Value table，但这将是一种矫枉过正。

因为这是一个多对多关系，我们需要一个三级关系 table，它有 2 个外键 (FK)（复合外键）- 一个 FK 是设备，第二个 FK是添加。这个第三级 table 还将有第三列 OPTION_VALUE 这是我们的关系属性，包含 4 个值作为其值集。我在下面画了一个小图来说明这个设计-

为以下简单示例设计架构的最佳方法是什么？

What is the best way to design the schema for the following simple example?

mysql

database

database-design

database-schema