HIS数据库设计

lt2000

请教在设计HIS数据库时，收费项目信息（包括药品、诊疗等）是不是要分成药品和诊疗两个表呢？

tanyiqiang

收费项目包括药品、卫材、诊疗项目三部分，共性部分放一个表，专有部分放另外的表，通过关键字关联起来。
软件设计很重要的是系统分析、架构设计，关系数据库是建立在关系代数的基础上的，好好补充一下这方面的知识吧。

henryge

好好学习。

ccwlm741212

无所谓的，分开也可以

sky_chenyu

一般是分开的

lt2000

请教各位，在设计系统时，整个系统只有一个病人基本信息，在门诊或住院时都用该信息，各位是怎么设计的？我看了一些系统，他们是门诊用门诊的病人信息，住院是用住院的基本信息，不能够共享。我设计是这样的，在病人门诊挂号时，查询病人基本信息，如果没有该病人的基本信息，那么就新建病人基本信息，然后再挂号；住院登记时也先查询病人基本信息，没有也进行登记基本信息，那么在下次病人来看病时，就不需要输入基本信息，而且门诊及住院的各个诊疗内容都关联到病人基本信息，那么自然就形成了病人的病历信息，只是表现时设计界面比较不好办而已；总之，系统的设计是围绕病人展开，各种单据信息都可能通过病人信息来组织成一个整体

ccwlm741212

这个问题我们以前讨论过, 一般来说挂号基本信息存在后,门诊和住院信息分开,可以通过挂号信息建立关联

tanyiqiang

所有信息在系统中都只有一个版本，即无冗余或极少冗余。病人信息只有一个，整个系统共享。

披发头陀

少冗余的代价通常就是：1、没办法回顾历史；2、性能低下

tanyiqiang

最初由 披发头陀 发布
[B]少冗余的代价通常就是：1、没办法回顾历史；2、性能低下 [/B]

对于1.没办法回顾历史，不与冗余相关，修改数据可以放在历史表，当然也可以在业务数据中保存当前字典的数据，各家有各法。
对于2.性能低下，主要是查询时要做连接操作，当然要付出代价，这个代价一直来都是能接受的，当今的服务器硬件与数据库软件的处理能力已经使这个问题不成为问题，如果成为问题，肯定的语句没写好，或者数据库设计有问题。