多数单位不缺钻孔资料，缺的是能查。1200 个孔散在七个版本的 Excel 里，对个孔号要翻半天，这时候钻孔数据库的价值不在存档，而在三秒内取到某一孔的某一层。
一、先想清楚存什么：钻孔数据库字段标准怎么定
换过三拨人的勘查项目，最先出问题的是孔号：ZK、ZK-01、ZK01 三种写法混在一张表里，合并时凭空多出四十多个重复孔。字段不定在前面，后面每一次查询都要替它还账。
主表我一般只留九个必填项：孔号、孔口坐标 X、孔口坐标 Y、孔口高程、终孔深度、开孔日期、终孔日期、勘查阶段、数据来源。分层表用孔号、起深、止深做联合主键，样品表用孔号加样号，三张表靠孔号串，改一个孔不必动其他两张表。这套钻孔数据库字段标准写下来就一页 A4，难的是让人签字认。
还要加一个审计字段，记录最后修改人和时间。钻孔数据库一旦被人手改过，缺这一列就查不出是谁动的，责任分不清，下一次还会被改回去。
判断条件很直白：孔数在 300 以内、单人维护，文件型数据库够用；超过 300 孔，或者三个人以上同时改数，就该换成 PostgreSQL 配 PostGIS，否则今天改的明天被覆盖。
它有走不通的时候。只有纸质柱状图、没有坐标的老孔，位置全靠图面配准，精度撑不起大比例尺定位，这类孔只能进参考图层，不能当钻探成果引用。钻孔数据库能替你管关系，管不了你没有的东西。
二、导入不等于建库：三步把返工挡在前面
最常见的事故是直接把 Excel 拖进库。三百个孔里六十个孔深用厘米记，柱状图拉出来高度差一百倍，图上看着像两个矿区。这就是钻孔数据库建库流程里最容易被跳过的一段。
我的顺序是三步。先做字段映射表：一列源字段、一列目标字段、一列转换规则，单位换算必须写在表里。再跑校验：坐标是否落在合理范围、孔深是否大于零、起止深度有没有重叠、必填项空值率多少。最后留一张原始快照表，把导入前的原始行原样存住，出错能回溯。
校验脚本别一次写全，先跑空值和单位两类，跑顺了再加几何判断。每到一批新孔都要重跑，脚本必须能反复用，钻孔数据库的干净程度全靠这一步撑着。
历史孔坐标是另一个坑。旧系统坐标系不同，转换完不要覆盖原字段，另开两列存原始坐标和转换参数，将来复核还对得上。跨投影带的项目也要留神，3 度带和 6 度带别拿一个参数硬转，按带分别投影再合并，否则图面偏移是公里级。这两条是钻孔数据库建库流程里最容易埋雷的地方。
三、ArcGIS Pro 与 MapGIS 10 各管一段
外业二十个人要查孔位和柱状，天天发 PDF 不是办法。这一段的原则是数据只放一处，展示分两头做，属于典型钻孔数据库服务发布的活儿。
ArcGIS Pro 负责建表、符号化和发布：孔位要素类发成要素服务并打开属性查询，密集区再配一套 1:5 万的切片底图；要素服务单次返回条数从默认 1000 提到 2000，前端仍按 50 条一页分。MapGIS 10 那边做孔柱三维和剖面出图，两边用 SHP、GDB 或 GeoJSON 交换，不来回导入导出。
字段别名要在发布前配好，别让外业看到 ZK_NO、DEPTH_M 这种代号。钻孔数据库的价值有一半在字段可读，另一半才在检索速度。
怎么选有判据：只看孔位分布，切片地图服务更稳，权限也不用配；要按岩性、深度筛孔段，必须走要素服务的属性查询，切片做不了这件事；要做柱状三维或剖面联动，交给 MapGIS 10 的孔柱模块或 Pro 的局部场景。这套钻孔数据库服务发布的路子，本质是把查询和数据源解耦。
边界同样清楚：涉密区数据不出内网，公有云只放脱敏后的孔位；坐标偏移量单独存档，否则过两年自己对不上账。上线后每周对一次数，要素服务的孔位数量与主表行数差得多，就说明有人绕过库直接改了表。
四、让人真的查得动：先把首屏做轻
野外手机上 4G 两格信号，打开一个两百孔的柱状页要等二十秒，多数人点第二次就关了。钻孔数据库三维展示做得好不好，先看首屏够不够轻。
做法是分三步：地图先只拉孔位点，一屏控制在两百个以内；点开某个孔再请求它的分层数据；列表分页 50 条，翻页不做全量重绘；高频的固定查询走缓存，别每次都打库。
手机端别给完整柱状图，给分层表格加一张剖面缩略，流量能省下来一半。钻孔数据库不是把图搬上网，是让人按条件把数取走。
判据按场景分：弱网移动端用切片加按需接口；单孔加载时间超过三秒就该拆接口，钻孔数据库三维展示的门槛从来不在建模，在加载。内网 PC 可以直连要素服务，响应更即时；三维柱状只给重点区，五十孔以内，超了按深度抽稀，只留主矿段。
这条线有天花板。两百孔以上一次加载必卡，垂直夸大调到再好看，也不能拿来量厚度，汇报能用，验收不能用。
同一套数据放在三种环境里，差别是可以量出来的：
表1 三种建库方案的查询性能与年维护投入
| 方案 | 百孔查询耗时（秒） | 年维护投入（人日） | 适用规模 |
|---|---|---|---|
| 共享台账文件 | 40–60 | 2 | 单项目，10 人内 |
| 数据库＋地图服务 | 1–2 | 8 | 多项目，跨部门 |
| 数据库＋三维发布 | 5–8 | 15 | 评审与汇报 |
【作者测算：按百孔规模、内网与公网各测三次取中位数推算，非官方数据】
五、关键判断清单
- 孔数超过 300，或三人以上同时改数 → 上 PostgreSQL 配 PostGIS，别继续共享台账。
- 只需要看图、不需要筛孔段 → 用切片地图服务，省掉要素服务的权限配置。
- 历史孔坐标系不统一 → 保留原始坐标字段，转换结果另存，不做覆盖。
- 有人要按岩性、深度查孔段 → 必须开要素服务的属性查询。
- 只做一次性汇报 → 用离线打包地图，不必维护在线服务。
- 数据涉密 → 内网部署，公网只放脱敏孔位。
六、边界与风险
有些情况不适合走这一套。
孔数不到 100、只有一个项目、一个人维护，建库加服务的投入大过收益，结构化 Excel 加统一孔号规则就够，不必为了上云而上云。
只有纸质剖面、缺坐标的孔占到一半以上时，服务化没有意义，先把图面配准和坐标补录做掉。
跨单位汇总时权属不清、口径不一致，先谈共享协议和字段对照表，直接建一个库会变成长期扯皮。
如果单位没有明确的数据责任人，也先别建。钻孔数据库有人建没人管，两年后字段会被改得面目全非，还不如不建。
还有一条容易忽略：三维柱状好看，但它不是量测成果，拿去评审做动画可以，拿去算资源量会出事。
七、落地建议
按周排，四步。
第一周清点孔数、统一孔号规则、锁定坐标系，产出一页 A4 的字段表，找负责人签字。
第二到三周建主表和两张分层表，把校验脚本跑通，先导 500 孔以内的数据做试点，别一次性全量。
第四到六周发布要素服务与切片，做一个列表加地图联动的查询页，先给三个人试用，收一轮反馈再放开。
第七周起再考虑三维，优先五十孔以内的重点区。每一步留个验收标准：字段表签了字、脚本能一键跑、服务能返回指定孔的记录，三条都过再进下一步。
门槛记一个数：孔数过 300 或协作人数过 3，才值得上服务；不到这个量，先把手上的表理顺。
八、结语
钻孔数据库真正的门槛不在技术选型，在字段和权属这两件脏活。ArcGIS Pro 负责把表做对、把服务发出去，MapGIS 10 负责把柱子立起来，工具都够用，难的是谁认账。先把三百孔以内的规则跑通，再谈上云，比一次铺开十个项目稳。
