企业官网建设流程全解析

简介：面向医疗信息化领域的Caché数据库开发文档合集，围绕HIS系统建设场景，系统梳理InterSystems Caché的部署、建模、编程与运维关键知识，适用于医院信息系统研发人员、数据库管理员及医疗IT运维团队。压缩包共有145个文件，以143份PDF技术文档为主体，另含1个HTML导航页面和1张产品示意图，整体大小77.18MB。PDF文档内容覆盖环境安装与基础配置、多维数据模型设计、MUMPS语言编程指南、API参考、高可用集群与灾难恢复策略、用户权限与数据安全配置、医疗业务报表与分析工具使用方法，并包含示例代码与项目样例，便于对照实践。适合需要快速上手Caché数据库、或正在优化现有HIS系统的后端开发工程师、数据库管理员及医疗IT运维人员，已有1031人学习使用。通过研读这套资料，能够形成从数据模型设计、系统开发调试到容灾加固的完整认知，直接辅助医疗业务系统的构建与维护，提升开发效率和系统稳定性。

1. Caché HIS数据库为什么难上手：先把三个底层差异看清楚

第一次在Caché里找数据，我花了一刻钟，因为导航工具里根本没有“表”这个概念。后来才彻底明白，Caché HIS数据库存数据靠的是全局变量（Global）这个多维结构，SQL、对象和维度只是不同视角。这套《医疗HIS系统Caché数据库开发文档资料》就是把“数据到底存在哪、怎么改、怎么查”这条主线串起来，核心覆盖Global操作、类定义、SQL混用、锁与事务、备份恢复。它适合三类人：替老HIS做二次开发但只会Oracle的开发者，维护Caché实例却只能重启服务的运维工程师，以及要接数据做报表的接口工程师。它不是语法手册，更像一套把开发闭环走通的项目笔记，跟着在测试库上敲一遍，基本功就立住了。

2. Caché在HIS里的立足点：Global存储、类映射与事务模型

2.1 一张挂号单在Global里是怎么存的

在Caché里，一切持久化数据最终都存在Global里。Global是一个稀疏多维数组，以^开头，在命名空间里可以被任意代码访问。以挂号数据为例，把患者主档和当日挂号信息按下标铺开，是这类系统最常见的数据形态。

; 写入患者主档，字段用分隔符拼接 Set ^HIS.Reg.Patient("Z0001")="张明|男|1978-02-11" Set ^HIS.Reg.Patient("Z0002")="李红|女|1990-07-23" ; 按下标取出姓名 Set name=$Piece(^HIS.Reg.Patient("Z0001"),"|",1) ; 用 $Order 遍历所有人，直到下标为空退出 Set id=$Order(^HIS.Reg.Patient("")) While (id '= "") { Write "病历号: ", id, " 内容: ", ^HIS.Reg.Patient(id), ! Set id=$Order(^HIS.Reg.Patient(id)) }

逻辑说明：第一段写两行患者数据，下标是病历号，内容是竖线拼接的字段串。Caché不校验内容格式，“|”的分隔只是业务约定。取出姓名时用$Piece按位取第一段，这比先拆成数组再取数要快。遍历用$Order从空下标开始，每次取下一个存在的下标，循环结束条件就是返回空字符串。因为没有物理行号的概念，$Order在顺序扫描里比直接枚举数值下标可靠得多。

参数说明：下标写成字符串在Global里完全合法，而且能跳过空节点；若写成数字，Caché会按数值排序，和字符串顺序不一致，混合下标时最容易踩坑。内容串里不要出现和分隔符相同的字符，否则$Piece取数就会错位。我在生产环境里会把字段分隔符换成$C(1)这类不可见字符，避免病人姓名、地址里出现竖线干扰解析。

Caché在HIS里经久不衰，一个重要原因是就诊数据天然就是树形的：一个患者多张就诊卡，一次就诊多组医嘱，一组医嘱多条明细。用关系型库表达这个结构要建四五张表加外键，而Global允许直接用嵌套下标表达层次关系。这是从Oracle转过来时最容易忽视的差异。

2.2 类定义、SQL与Global：三者谁是真正的存储

类定义（%Persistent父类）在编译时生成一套Storage映射，Storage把属性映射到命名空间内的Global；SQL表只是这套映射的只读视图。所以一个持久类怎么存，最后还要看Storage映射怎么配。先写一个简化的患者主档类。

Class HIS.Reg.Patient Extends %Persistent { Property PatNo As %String(MAXLEN=20); Property FullName As %String(MAXLEN=40); Property Gender As %String(MAXLEN=6); Property BirthDate As %Date; Index PatNoIndex On PatNo [ Unique ]; Index NameIndex On FullName; }

这段代码编译后会生成两个系列的Global：^HIS.Reg.PatientD用来存记录，D是Data的缩写；^HIS.Reg.PatientI下面按下标存各索引。PatNoIndex定义成Unique时，插入重复病历号的请求会直接回滚。索引名和属性名可以不同名，它就是一个“下标组合”的命名空间。

参数说明：MAXLEN影响字符串的存储上限和交互窗口里的长度校验，写入超长内容时类保存会报错，所以这个值不是随便填的。%Date在磁盘上是整数存储，显示时再转成日期格式，SQL里处理它时要注意内部存的是从1841年起的“天序号”，老系统做数据迁移时很容易在这个点上算错年份。

什么时候不该直接碰Global？如果项目里已经有类定义，绕过类写Global等于绕过了数据校验和默认值逻辑。我的习惯是：开发阶段可以用Global快速验证数据形态，生产代码统一走类方法，只有对性能极度敏感且有监控兜底的模块才特许直接索引。这么做的好处是，将来升级要换存储布局时，只有类定义和映射要改，应用层代码不受牵连。

2.3 事务与锁：HIS并发写入为什么容易锁冲突

HIS里并发最高的写操作集中在挂号、收费、发药确认。Caché的锁机制以Global节点为对象，常见锁模式分为共享锁和排他锁，锁名称由代码自行约定。

; 尝试获取指定节点的共享锁，允许3次重试 Set ok=$System.Lock.Lock("^HIS.Reg.PatientZ0001","S",3) If ok'=1 { Write "锁获取失败，有人正在改这条患者记录", ! Quit } TSTART Set ^HIS.Reg.Visit("V2025120001")="已分诊|分诊台A" TCOMMIT Do $System.Lock.Unlock("^HIS.Reg.PatientZ0001","S")

逻辑说明：先锁住患者节点再更新就诊状态，是为了防止分诊和收费并发时读到中间态。锁获取的第三个参数是重试次数，用0表示立即返回不等待，用正数表示最多重试指定次数。TSTART开启显式事务，TCOMMIT提交，事务提交时会同步释放事务内获取到的临时锁。如果中间出错，用TROLLBACK回滚整段操作。

参数说明：锁名称不一定要和存储节点严格对应，只要进程间约定一致，它更像一把业务锁；但按存储节点加锁可以顺带阻止数据被改写。从Oracle过来的人最反直觉的一点是：无锁模式下两个进程同时改同一个节点，后写覆盖先写，Caché不会像关系型库那样自动报错。事务要自己包，锁要自己申请，写代码时脑子里得有这条线。

锁冲突通常有两个来源：一是事务跨度太长，二是事务里夹杂了不必要的读取。收费模块往往会先读患者余额、再写账务、再更新挂号状态，事务一拉长，高峰期多个事务就在存储节点上互相等。对策是先缩事务边界，把只读操作挪到事务外面；以及在上游应用层控制同一患者记录上的操作串行化，不要把并发压力全丢给数据库。

3. 从文档包复现一个患者主索引：类定义、Studio与导入验证的完整路径

3.1 文档资料先看哪几块，按什么顺序翻

这类资料包里通常有六类东西：环境安装与许可说明、开发工具（Studio或Atelier）的操作说明、Caché对象脚本和SQL样例、管理门户与DBA命令、备份恢复手册、以及一组演示用的项目源码。很多人拿到手爱直接翻语法部分，翻完合上，什么都没留下。建议的顺序是先做环境安装和命名空间创建，然后挑一个演示源码导入Studio，编译成功后立刻去看它生成的Global。命令语法只有在能看到物理存储结构变化的时候，才记得住。

表格是参考顺序，不是章节顺序。如果你的目标就是快速上手开发，第六项演示源码最值得花时间；如果目标是维护老系统，第二项和第五项优先。

3.2 在命名空间里建第一个持久类并完成编译

第一步，建测试命名空间。常见做法是在管理门户里用“系统管理—配置—命名空间”创建，终端下的等价路径如下：

zn "%SYS" Do ##class(Config.Namespaces).Create("HISDEMO", "c:\cachedemo\hisdata") zn "HISDEMO" Write $Namespace

逻辑说明：第一条切换到%SYS命名空间才有权限创建；第二条调用配置类创建命名空间，第三个参数是数据库路径，路径不存在时会自动建目录；zn命令负责切换命名空间。参数说明：数据库路径最好单独放一个目录，不要放到Caché安装目录下，否则备份恢复时容易牵连系统库。命名空间名建议大写，因为它会渗透到SQL表名和类包名里。

第二步打开Studio，新建一个类，把上一章的患者类定义粘进去，保存后编译。也能用命令行直接编译：

Do $System.OBJ.Compile("HIS.Reg.Patient","c")

参数“c”表示编译并保留编译器日志，失败时能翻出错在哪一行。编译成功后在Terminal里验证Global是否生成：

Write $Data(^HIS.Reg.PatientD), ! Write $Data(^HIS.Reg.PatientI("PatNoIndex"))

第一行返回非0代表数据Global存在，第二行返回非0代表Unique索引Global生成了下标内容。如果两者都是0，说明类没有真正编译，或者映射到了别的命名空间，这时候先回Studio看Storage页签。

3.3 建完类后做三件事：插入、索引查询、看执行计划

对象方式插入一条数据：

Set p=##class(HIS.Reg.Patient).%New() Set p.PatNo="Z0001" Set p.FullName="张明" Set p.Gender="男" Set p.BirthDate=$ZDH("1978-02-11",3) Set sc=p.%Save() Write sc

逻辑说明：%New创建对象实例，设置属性，%Save持久化，保存成功返回1。$ZDH把文本日期转成Caché内部天数，第二个参数是日期格式编号。这里推荐统一使用标准格式的日期格式，避免英美日期顺序混淆。老系统导入数据时，经常因为日期格式编号没对上，导致所有生日都偏移，这种错误还特别难发现。

然后验证索引查询：

SELECT PatNo, FullName FROM HIS_REG.Patient WHERE FullName %STARTSWITH '张'

%STARTSWITH匹配前缀，配合NameIndex能走索引前缀查找，不会逐行扫。如果写成“FullName='张'”，则永远查不到，因为表里存的是完整姓名。按模糊记忆查患者姓名时，%STARTSWITH也比“LIKE '%张%'”快很多。想看查询有没有走索引，在SQL语句前加SHOWPLAN，Caché会输出执行计划，文档包里对这类操作有专门说明。

4. Caché开发问题排查：从HIS项目现场带回来的五类踩坑记录

4.1 中文姓名排序乱序：ORDER BY结果不是拼音顺序

现象：用ORDER BY FullName查患者列表，出来的顺序有时按Unicode码点，有时按录入顺序，和预期完全对不上。

原因：Caché的字符串默认Collation按二进制或Unicode码点排序，不识别拼音。HIS的名单列表又特别讲究翻页找人，这个坑几乎总会碰到。

解决：对姓名索引显式指定排序规则。

Property FullName As %String(MAXLEN=40, COLLATION="Pinyin");

重新编译类后，SQL的ORDER BY FullName就会按拼音排序。老实例不给改字段时，可以给SQL排序字段套一层函数处理，但代价是索引失效；表数据量大时，这个曲线方案会明显变慢。所以最好还是从索引定义上解决，底子干净，后面报表模块不遭罪。

4.2 收费窗口锁冲突：高峰期事务频繁超时

现象：每天就诊高峰时段，收费窗口偶发卡顿，错误日志里反复出现“Lock conflict”。

原因：收费流程里事务跨得太长。窗口人员录入慢，事务里带着需要写入的医嘱节点，后一个窗口的更新必须等前一个窗口释放锁，高峰期自然排队。

解决：砍事务边界，只把最后写库的几步放进TSTART/TCOMMIT，中间读取全部放在事务外；把“先检查后修改”改成“条件写”。

UPDATE HIS_REG.Account SET Balance=Balance-80 WHERE PatNo='Z0001' AND Balance>=80

“条件写”把两步合成一步，底层对上锁时间窗口就短了一半。锁升级阈值也要留意，单节点写操作一旦锁升级，可能变成全表锁，这时候症状就从一个窗口卡变成一层楼卡。把锁超时时间调到合理范围，同时监控锁冲突日志，出问题时有据可查。

4.3 SQL查得到的记录，$Order遍历Global却找不到

现象：SQL里SELECT能查到10条记录，用ObjectScript的$Order遍历对应数据Global，却少了几条。

原因：第一种可能是数据Global实际是索引节点而不是数据节点，SQL走了索引；第二种可能更隐蔽，类的Storage映射把部分属性单独分配到了另一块Global，数据和预想的名字对不上。

解决：在管理门户里打开类的Storage编辑器，看它具体生成了哪些Global，排查时以Storage定义为准，不要靠猜。判断节点是否存在用$Data，不要依赖$Order第一次返回的值；$Order的返回值在某些边界条件下会被误解为空，实际只是从当前下标跳到了下一个空节点。

4.4 导出导入后中文乱码与字符串被截断

现象：把某张表导出成文本再导入另一套环境，中文变成问号或残缺字符，重启实例也无效。

原因：老版本Caché导出文件默认带系统编码，导入环境的字符集设置和导出端不一致；字符串字段的MAXLEN设得太短，保存时被静默截断，这个更隐蔽，因为界面上不报错。

解决：导出前核对两套环境的默认字符集；导入后跑一个对账脚本，按主键比对关键字段长度和内容；业务关键字符串字段把MAXLEN调大，尤其病历备注这类文本，宁长勿短，老库里截断数据追不回来，只能人工补录。文档包里的数据迁移章节一般会附带这类对账脚本模板，直接改字段名就能用。

4.5 备份恢复演练发现的日志疯狂增长

现象：做了两次在线备份，数据目录空闲空间从60%掉到20%，Journal文件数量暴涨。

原因：备份默认会开启日志归档，恢复演练又在同一实例上执行，旧日志没及时清理，新日志照常累积。

解决：到管理门户里核对日志自动清除策略。常见做法是备份后立即切换日志，并设置归档目录，归档目录单独挂一块盘；给日志目录单独配置监控告警，不要等整个数据盘满了再处理。恢复演练前，先确认演练环境和生产环境的日志路径没有共享，否则一次误操作就把生产日志冲掉。

5. HIS业务模块怎么落地：ObjectScript、SQL与Global三者的实际边界

5.1 写操作走类方法，读操作交给SQL

HIS里每个写操作背后都带着业务规则，退费必须校验原收费流水存在且未被冲正，发药必须校验处方状态。直接用SQL UPDATE能绕开业务层，短期痛快，长期维护痛苦。我的做法是围绕类封装写方法，读和统计放开用SQL。

ClassMethod Charge(patNo As %String, amount As %Numeric) As %Status { Set account=##class(HIS.Reg.Account).%OpenId(patNo) If '$IsObject(account) Quit $System.Status.Error(5001,"患者账户不存在") If account.Balance < amount Quit $System.Status.Error(5002,"余额不足") Set account.Balance=account.Balance-amount Quit account.%Save() }

逻辑说明：%OpenId按主键打开账户对象，$IsObject判断是否打开成功。余额不足直接返回错误，最后才落库。这个方法在应用层是唯一的扣费入口，所有调用方都必须经过它。返回值用%Status对象而不是简单整数，调用方要用$System.Status.GetErrorText()去显示具体错误文本。

参数说明：错误码5001和5002是自定义范围，不同模块要预留错码区间，别全挤在一起。这类方法越短越好，因为它会被窗口客户端频繁调用，一旦里面混入报表逻辑，响应时间立刻恶化。

5.2 病历长文本：用流字段存而不是堆在普通属性里

把病历全文塞进字符串属性，小数据量时看不出问题，大数据量时保存会卡，读取也慢。正确做法是把长文档定义成流类型的字段。

Property MedicalNote As %Stream.GlobalCharacter; Method SaveNote(patientId As %String, noteText As %String) As %Status { Set note=##class(HIS.Reg.Patient).%OpenId(patientId) Set stream=note.MedicalNote Set sc=stream.Write(noteText) If $System.Status.IsError(sc) Quit sc Quit note.%Save() }

逻辑说明：流字段不是一次性把全文塞进内存，Write方法把内容追加到后台分配的Global子节点里，读取时按流方式逐段取，前台翻页就不容易卡。参数说明：%Stream.GlobalCharacter的子节点由系统管理，外部不要手工改；它有独立的大小统计和移动指针操作，数据完整性交由类层维护。存病理报告、检查所见这类长文本，这一条能省很多事后补数据的力气。

5.3 统计报表：位图索引与SQL视图怎么组合

HIS里统计报表大多是“按时间范围统计就诊人数、费用汇总”，这种查询最怕WHERE条件全表扫。位图索引就是为这种场景准备的。

Property VisitDate As %Date; Index VisitDateIdx On VisitDate [ Type = bitmap ];

位图索引用一个节点描述整个数据范围的位图，存储占用小，聚合计算特别快。按月的费用合计优化效果很明显。建一个视图收口查询路径：

CREATE VIEW HIS_V_VISIT_SUMMARY AS SELECT VisitDate, COUNT(*) AS Cnt, SUM(TotalAmount) AS Amt FROM HIS_REG.VisitLog GROUP BY VisitDate

报表工程师只查HIS_V_VISIT_SUMMARY，不给他们底层表的直连权限，查询路径就稳定在数据库控制范围内。开发期间要定期看视图的执行计划，确认它走位图索引而不是Huge Scan；一旦数据量涨上来，位图索引的维护成本也会上升，频繁写入的表不建议无脑加位图。

6. 进阶：用“下标即索引”设计时间序数据，顺带把统计报表提速

在一套就诊流水表的改造里，我把主键从“自增序号”调整为“日期+流水号”的多级下标，改动量不大，效果非常直接。

; 按天存就诊流水：下标是日期+流水号 Set ^HIS.Reg.VisitFlow("2025-11-01","A0001")="张明|挂号|120" Set ^HIS.Reg.VisitFlow("2025-11-01","A0002")="李红|收费|85" ; 统计某天的总费用 Set total=0 Set seq=$Order(^HIS.Reg.VisitFlow("2025-11-01","")) While (seq'="") { Set total=total+$Piece(^HIS.Reg.VisitFlow("2025-11-01",seq),"|",3) Set seq=$Order(^HIS.Reg.VisitFlow("2025-11-01",seq)) } Write "当日费用合计: ", total

逻辑说明：日期作为第一层下标，查询单天记录时只扫该日期下的子节点，不用翻全年数据。统计某月时逐天取数，整个过程没有“索引查一遍再回表查一遍”的二次查找。参数说明：日期字符串格式必须保持对齐，“2025-11-01”和“2025-11-1”的排序顺序不同，下标建议统一零填充格式，要么都用带横线的，要么都用YYYYMMDD，不要混用。

这套设计配合位图索引后，报表查询基本不再碰高代价的排序和全遍历。但要提醒一句：直接写Global是性能方案而不是架构方案，一旦这么写了，索引、事务、权限都不再由类层自动管理，所以我只建议在导出类数据或专用报表表上用它。真要在生产账号上这么干，必须把监控和恢复方案一并配套。

回想那次改造，最深的教训不是某一条语法，而是那句总被忽略的提醒：Caché里“下标即索引”，存结构要比写查询花更多心思。从那以后，我每次拿到新的存储需求，都会先在本子上画树形下标，画到没有多余层级才动手建类；这个习惯帮我少趟了很多坑。希望帮到你。

本文还有配套的精品资源，点击获取