医院业务工作流中有一张申请单，上面记录了本次住院病人的基本信息和需要冲负的费用项明细。
设计申请表的时候，我将病人的基本信息，包括姓名，性别，出生日期，本次住院的病情等数据都设计在申请主表中。提交给dba的时候，他却说这样设计是数据冗余，只需要在申请主表中保留病人主索引id和住院的主id即可，数据展示的时候再去关联病人信息表和住院信息表。我们医院的病人主索引表和住院信息表都是大表，几百万上千万条数据，从建库到现在都没有做过归档分割，虽然主键有索引，但是也不应该这么干啊。而且申请单是个快照单据，创建单据的时候就该保存当时的完整信息，至于工作流流转当中信息发生变化，都以当时申请提交的数据为准，改成关联的话，以后数据有变化，比如病人改名，销户或者住院信息变更，我这张申请单的数据显示都得跟着变。大家讨论下怎样设计才合理？

明显dba是对的
你就是不想承认自己设计不合理还改名呢 你咋不说病人改性别

根据实际情况，不光要和DBA商量，还要和医院的业务主管商量

医院的数据往往还要牵扯到纠纷取证的问题，快照固然是最合理的，但是往往国内更需要合情……

lz 你把“快照单据”的需求给 dba 怂回去，看他的“视图”思路怎么解决（委婉一点，直接和他讲业务上有查看历史记录的需求），要查历史记录只能冗余存储。

关键还是你这个业务是以当时数据为准还是以最新数据为准，以最新数据就只能关联，以当时数据就只能建快照，这个时候就不是冗余数据，而是真实业务数据了。

看你们的需求，不过千万级别的数据并不算大，如果不是天天有人查着玩，并不需要特别高的性能
需要查询的单开视图或者缓存就是了

这有什么冗余的?履历不需要查么?

要建个履历表放履历啊,再把最新的情况更新到主表里不就完了.

dba没毛病 听人家的吧，别快照不快照的，快照也可以给病人基本信息建快照，病人基本信息明显是变动概率几乎没有的，没必要跟着主表被考来考去
说句难听话，我要查个病人基本信息，主表还要跟着被折腾嘛？
另外，说数据变化的，你没干过dba你这就是门外汉了，原则上，db里除了update状态字段，是不应该有任何更新信息字段的update语句的，信息字段永远只能有insert，不能有delete和update，天然保留历史所有变更轨迹

[本帖最后由 xpressure 于 2017-5-17 14:53 编辑]

我们也有类似的业务系统，设计是业务库存一份，成果库存一份。业务库中，以业务件为核心，人会重复。成果库，人是唯一的。

当然是dba对，如果你要保存原始单据信息应该另外生成一张表，这张表不进入工作流只用来备份

数据冗余的问题不是浪费空间，而是在将来更新的时候会导致数据不一致

明显冗余更好，你是对的

你这个是业务问题。

dba正确；病人改名，销户或者住院信息变更这些不正要分表处理更合理么？而这些信息不管怎么改，主表存储的ID或者身份证ID是唯一且不会变的

病情放主表，你这冗余。。。。。
人归人，就诊归就诊
需要独立用途的特殊需求view解决。

你对的。
你们dba不熟悉业务

引用关系不能更改历史单据，否则将来有人来你们医院闹事你们就该哭了。