对于以下数据,我一直在使用不同的模式(多年未触及的数据库),但似乎没有理想的。
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)。
答案 0 :(得分:2)
它是(软件)附加组件和设备之间的多对多关系。多对多关系本身具有属性option_value,该属性将是4个值的枚举集合(包括,不适用,付费或禁用(未经测试))。 你也可以将这个枚举作为一个单独的Option_Value表,但这将是一个过度杀伤。
因为,这是一个多对多关系,我们需要一个三级表,它将有2个外键(FK)(一个复合外键) - 一个FK到DEVICE,第二个FK到ADDON。此第三列还将具有第三列OPTION_VALUE,它是我们的关系属性,包含4个值作为其值集。我在下面画了一个小图来说明这个设计 -
答案 1 :(得分:0)
我建议使用此
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 |
----------------------------------------------