许多复选框的复杂数据库设计答案

【问题标题】：Complex database design for many checkboxes许多复选框的复杂数据库设计
【发布时间】：2017-07-30 03:38:32
【问题描述】：

我目前正在为当地医院创建一个网站。我目前面临的问题：网站有太多的复选框和字段，根据复选框启用/禁用。

这是网站的网址：http://ali.ezyro.com/adan/myForm.php

由于我对数据库的经验很少，设计数据库以保存本文档的所有数据的最佳方法是什么？

【问题讨论】：

我认为最好的方法是按部分划分，1 个部分 = 1 个表。
1) 设计一个表格来存储患者信息，例如。病人。 2）为您拥有的每个块设计一个单独的表格。 3) 将 Patient 表的外键保留在步骤 2 中创建的所有其他表中。 4) 如果您不想将 Patient 键保留在其他表中，那么您也可以在它们之间创建关系。 5) 如果您更喜欢第 4 步，那么患者密钥必须存在于第 2 步中创建的至少一个表中

标签： mysql sql database database-design entity-relationship

【解决方案1】：

在这种情况下，关系数据库可能不是您的最佳选择 - 这完全取决于数据在系统中的使用方式。

直接的选择是为每位患者设计一张（非常宽的）桌子。每个属性都建模为一列；多值属性（复选框）对于每个有效选项都有一列，需要从有效选项列表中查找的单值属性使用保存有效查找的表的外键（例如，在患者表中，您有一个名为cervical_collar_id 的列，并且您有一个名为cervical_collar_values 和1 - prehospital, 2-on arrival, 3-not required 的单独表。

这使您可以存储数据，并使用标准 SQL 高效地查询数据（例如，查找所有带着院前颈托的患者）。 “如果您选择框 x，则框 y 成为必需”逻辑可能应该存在于应用程序中，而不是您的架构中。

但这是一个难以使用的设计 - 向患者记录添加属性并非易事。宽桌子通常是一个不好的迹象。

您可能会认为这是一件坏事，并选择“实体/属性/价值”设计。许多 Stack Overflow 的答案会告诉你这样做的好处和坏处——谷歌是你的朋友。 TL;DR：即使是中等复杂的查询也几乎是不可能的。

您可能决定将数据存储为文档 - 大多数数据库引擎存储 JSON 和 XML，并允许您有效地查询这些数据。它的好处是更易于开发和更改 - 但您会失去关系模型为您提供的内置验证。

【讨论】：