数据量会累加到特别大的表(MS-SqlServer),该如何分表?或者如何改进?

天台道人 发布于 2014/04/02 12:54
阅读 2K+
收藏 0
改进的目的:即不影响业务规模的提升,又不至于把增删查改的Sql语句搞得太复杂太低效。


应用场景:我们生产了方便医院护士查房用的仪器,现在开发的配套软件系统,需要确定后台数据库。整套系统和医院原有系统是相对独立的。一般医院有几十到一两百名数量的护士,几百到一千多张病床(一般满员),每天护士都要对这些病人进行3~6次护理操作,每次操作的记录都要存入现在我要设计的这个数据库。
一家中等规模医院每年门诊新增病人数量大约在1~2千万。


我的数据库设计中,其他部分像是仪器信息、系统基本参数表等等都OK,现在觉得不太合理的就是病人查房信息的管理这一块,现在设计如下:


patient_list表 - 存放整个系统中所有病人的基本信息
字段如下:
[patient_id] [varchar](32): 病人ID
[rcd_generate_time] [datetime]: 记录生成时间
[rcd_last_update_time] [datetime]: 记录最后修改时间
[patient_name] [varchar](64): 病人姓名
[sex] [int]: 性别
[age] [int]: 年龄
[height] [int]: 身高
[height_unit] [varchar](16): 身高单位,可以是“cm/inch”等
[birthday] [datetime]: 出生日期
[telephone] [varchar](20): 电话号码
[nationality] [varchar](128): 国籍
[nation] [varchar](64): 民族
[profession] [varchar](64): 职业
[marital_status] [int]: 婚姻状态,0-未婚,1-已婚
[unit] [varchar](256): 单位
[addr] [varchar](256): 地址
[past_history] [varchar](1024): 既往疾病史
[allergies_history] [varchar](1024): 过敏史
[medicare] [int]: 是否医保,0-不是医保,1-是医保
[credentials_name] [varchar](64): 证件名,可以是“身份证/学生证”等
[credentials_num] [varchar](128): 证件号码






patient_state_xxxxxxxx表 - 存放病人ID号为xxxxxxxx的该病人的状态(入院、出院等)信息,每个病人都有一张这样的表
字段如下:
[rcd_generate_time] [datetime]: 记录产生时间,精确到秒
[action] [varchar](64): 行为,可以是
“admissio/ischarge/surgery_begin/surgery_end/move”,分别表示“入院/出院/手术开始/手术结束/更改科室病区床号”
[admission_num] [varchar](64): 入院号
[person] [varchar](64): 登记人员姓名
[department] [varchar](64): 科室
[ward] [varchar](64): 病区
[bed_num] [varchar](64): 床号






patient_care_xxxxxxxx表 - 存放病人ID号为xxxxxxxx的该病人的护理信息,每个病人都有一张这样的表
字段如下:
[rcd_generate_time] [datetime]: 记录产生时间
[mnt_id] [varchar](20): 监护仪ID
[nurse] [varchar](64): 护士姓名
[vital_hr] [int]: 心率
[vital_pr] [int]: 脉搏
[vital_st] [float]: ST段
[vital_sys] [int]: 收缩压
[vital_dia] [int]: 舒张压
[vital_map] [int]: 平均压
[vital_spo2] [int]: 血氧
[vital_blood_sugar] [float]: 血糖
[vital_blood_sugar_unit] [varchar](16): 血糖单位,可以是“mg/dL”、“mmol/L”
[vital_etco2] [int]: 呼末二氧化碳
[vital_fico2] [int]: 吸入二氧化碳
[vital_temp_type] [varchar](16): 体温类型,可以是“ear/head/oral/ axillary/rectal”,分别表示“耳温/额温/口温/腋温/肛温”
[vital_temp] [float]: 体温值
[vital_temp_unit] [varchar](16): 体温单位,可以是“c/f”,分别表示“摄氏度/华氏度”
[vital_resp] [int]: 呼吸
[vital_awrr] [int]: 
[vital_pvc] [int]: 
[vital_pi] [float]: 
[score_MEWS_conscious_index] [int]: MEWS评分
[score_GCS_eyes_score] [int]: 格拉斯哥睁眼反应指数
[score_GCS_lang_score] [int]: 格拉斯哥语言反应指数
[score_GCS_motion_score] [int]: 格拉斯哥肢体反应指数
[score_PAIN_score] [int]: 疼痛评分,可以是0、2、4、6、8、10
[score_BMR_score] [int]: BMR评分
[body_weight] [float]: 体重
[body_weight_unit] [varchar](16): 体重单位,可以是“kg/pound”
[body_abdominal_circumference] [float]: 腹围
[body_abdominal_circumference_unit] [varchar](16): 腹围单位,可以是“cm/inch”等
[in_nasogastric] [int]: 鼻饲,0-未进行,1-已进行
[in_vein] [int]: 入量~鼻饲,0-未进行,1-已进行
[in_oral] [int]: 入量~口服,0-未进行,1-已进行
[in_tpn] [int]: 入量~TPN,0-未进行,1-已进行
[out_urine] [int]: 尿出量
[out_urine_unit] [varchar](16): 尿出量单位,可以是“ml/time”
[out_defecate] [int]: 大便出量
[out_defecate_unit] [varchar](16): 大便出量单位,可以是“ml/time”
[out_sputum] [int]: 痰液出量,单位“ml”
[out_sweat] [int]: 汗液出量,单位“ml”
[out_vomit] [int]: 呕吐出量,单位“ml”
[out_bile] [int]: 胆汁出量,单位“ml”
[out_blood] [int]: 出血量,单位“ml”
[out_drainage] [int]: 引流出量,单位“ml”
[out_stomach] [int]: 胃管出量,单位“ml”
[out_text_desc] [varchar](1024): 出量文字补充描述
[basic_care_turn] [int]: 翻身护理,0-未进行,1-已进行
[basic_care_fog_suck] [int]: 雾吸护理,0-未进行,1-已进行
[basic_care_skin] [int]: 皮肤护理,0-未进行,1-已进行
[basic_care_perineum] [int]: 会阴护理,0-未进行,1-已进行
[basic_care_oral] [int]: 会阴护理,0-未进行,1-已进行
[basic_care_lung_percussion] [int]: 肺部扣打护理,0-未进行,1-已进行
[basic_care_tube] [int]: 管道护理,0-未进行,1-已进行
[basic_care_infrared_radiation] [int]: 红外照射护理,0-未进行,1-已进行
[observation_care_effect] [varchar](2048): 病情观察、护理措施、效果的文字补充说明
[first_care] [int]: 首次护理,0-非首次护理,1-首次护理,该属性为0表示当前记录只有first_care之前的属性(也就是非首次护理相关的参数)有效,否则,first_care之后的属性(也就是首次护理相关的参数)有效
[first_care_allergies] [varchar](1024): 首次护理登记的过敏史
[first_care_falling_bed_score] [int]: 首次护理登记的坠床跌倒评分
[first_care_pressure_sores_score] [int]: 首次护理登记的压疮评分
[first_care_past_history] [varchar](1024): 首次护理登记的既往疾病史
[first_care_disease_name] [varchar](512): 首次护理登记的疾病名称
[first_care_now_taking] [varchar](1024): 首次护理登记的现服药
[first_care_other] [varchar](1024): 首次护理登记的其他需要说明的情况
[first_care_brief_history] [varchar](1024): 首次护理登记的简要病史





每个病人都有一张“patient_state_xxxxxxxx”和“patient_care_xxxxxxxx”表看上去比较怪异,也不符合什么三大范式,这样做的原因是,用分表来避免使对病人数据的回访成为系统瓶颈,(看到某医院系统中数据库导致整个系统卡死就是因为一张表的读写并发频繁)。


数据量最大的就是patient_care病人护理信息表,该如何分表,我觉得我这样做不合理,因为病人越多表越多的话,有可能某些查询就需要遍历很多很多的表。请教各位,这样的数据累加会很大很大的表,该如何分表?

加载中
0
jwjiang
jwjiang

这种分表方式在电力行业也是非常常见的,也有按时间来分的,不过一切都是跟业务紧密挂钩的,你给出的这些信息根本不足以提出意见,我只能说你这种分表方式是科学的,在没有进一步的业务需求了解情况下没法判断你的方式是好是坏,至于XX范式不用那么在意,一切以业务的流畅为准。

0
魔力猫
魔力猫

可以考虑分区,毕竟你查询的也只有最近一段时间内的护理情况。医院除非出现问题和科研,一般不会看以前病人的记录。所以你按照时间分区应该可以解决这个问题。至于范式,建议业务上尽量消除冗余。

事后的查询可以通过物化视图等方式进行数据清洗处理后提供查看,毕竟这种记录是只读追加的,没有人可以反复改病例不是。

0
晴风晓月
晴风晓月

笑话,虽然我也不一定要说什么三大范式,但一个病人一张表,这不是天大的笑话吗?

看到这句没有:每年门诊新增病人数量大约在1~2千万

这说明了什么问题,一年下来这个数据库光表就得1~2千万,还TM业务需求,可能吗?三大范式虽然很多时候我们只认为它是理论,不是一定要遵守的,但至少我们可以用它来评价数据库设计的好坏。还是好好地设计数据库吧


晴风晓月
晴风晓月
回复 @清云道长 : shit, 我没看懂? patient_state_xxxxxxxx表 - 存放病人ID号为xxxxxxxx的该病人的状态(入院、出院等)信息,每个病人都有一张这样的表
天台道人
天台道人
边边去
0
C
ChenElton

以床位作为一个维度产生当前在院病人护理信息表(表的数量永远等于床位数),出院时病理信息转入统一的病理历史信息表,历史病理的查询本身是一个发起机率较小的动作

以上~对你的架构修改最小

天台道人
天台道人
我比较认可这个办法。 现在我们系统还没有正式使用,所以改动再大都是可以接收的。如果你觉得有更好更彻底的办法,请你指教!
天台道人
天台道人
我比较认可这个办法。 现在我们系统还没有正式使用,所以改动再大都是可以接收的。如果你觉得有更好更彻底的办法,请你指教!
返回顶部
顶部