Mar*_*une 17 sql database database-design
我的朋友正在建造一个供不同的独立医疗单位使用的产品.
该数据库存储了在不同时间进行的大量测量,如温度,血压等...
让我们假设这些都是在一个名为表中所保持exams的列temperature,pressure等...(以及id,patient_id和timestamp).大多数测量都存储为浮点数,但有些是其他类型(字符串,整数......)
虽然这些测量中的许多都是由他们的产品处理的,但它需要允许不同的医疗单位记录和处理其他自定义测量.一个非常漂亮的用户界面允许管理员编辑这些海关字段,指定其名称,类型,可能的值范围等...
他不确定如何存储这些自定义字段.
他朝一个单独的表倾斜(比如一台custom_exam_data与像场exam_id,custom_field_id,float_value,string_value,...)
我担心这会使搜索更难以实现且效率更低.
我倾向于直接修改考试表(同时避免使用某些方案冲突列名称,例如使用下划线为所有自定义字段添加前缀或将其命名为custom_1,...)
他担心动态修改数据库并为每个医疗单位设置不同的模式.
希望一些有更多经验的人可以在这个问题上权衡.
笔记:
他正在使用Ruby on Rails,但我认为这个问题几乎与框架无关,只是因为他只是在SQL数据库中寻找解决方案.
我简化了这个问题,因为自定义字段需要可用于多个表,但我相信这并不会影响我们的方向.
(已添加)一个非常通用的报告模块需要搜索,排序,生成此数据的统计信息等,因此需要将此数据存储在相应类型的列中
(已添加)将过滤用户输入,标准字段以及自定义字段.例如,将在给定范围内检查数字(不能具有-12或+444的温度)等等.因此,转换为适当的SQL类型不是问题.
Dou*_*rch 10
多年来,我不得不多次处理这种情况,我同意你最初的想法是直接修改数据库表,并使用动态SQL生成语句.
创建字符串UserAttribute或Key/Value列首先听起来很吸引人,但它会导致内部平台效应,您最终不得不重新实现外键,数据类型,约束,事务,验证,排序,分组,计算等.人.在你的RDBMS里面.您也可以只使用平面文件而不是SQL.
SQL Server提供的INFORMATION_SCHEMA表允许您在运行时创建,查询和修改表模式.这有完整的类型检查,约束,事务,计算,以及您已经内置的所有内容,不要重新发明它.
奇怪的是,当有一个记录良好的模式时,很多人为此提出了临时解决方案:
两种选择是XML和嵌套集.XML更易于管理,但通常很慢.嵌套集通常需要某种类型的专有数据库扩展,而不会像SQL Server 2005+中的CLR类型那样混乱.它们违反了第一范式,但仍然是性能最快的解决方案.
Microsoft Dynamics CRM通过在每次更改时更改数据库设计来实现此目的。我觉得很讨厌。
我会说一个更好的选择是考虑一个属性表。即使这些经常被人们反对，它也为您提供了所需的灵活性，并且您始终可以使用动态SQL创建视图以再次将数据移出。只需确保在创建这些视图时始终使用LEFT JOIN和FK，以便Query Optimizer可以更好地完成其工作。