2026年10月23日 · tech-expert.moscow编辑部
首先确定究竟应交付什么
“可用数据库”可能指不同内容：表结构、一组测试记录、生产数据副本，或包含配置的现成系统实例。因此，核查应从技术任务书、合同附件、约定的交付程序及有关成果组成的往来通信入手。需要具体参照：部署后应可访问哪些数据和功能，覆盖哪个时段，以及应在何种环境中运行。
宜列出预期材料清单，并逐项注明实际收到的文件、链接或访问权限。另行记录交付日期、接收方式及项目版本。这有助于区分组件缺失、无法打开组件和与约定内容不符这几种情况。仅有一个名为backup的文件夹，并不能证明其中包含适用的备份。
源代码、架构与数据承担不同任务
代码描述应用逻辑。数据库架构规定存储结构。迁移文件按顺序修改该结构。初始数据可能用于创建用户角色、状态、配置或基础目录。生产记录则包含运行过程中积累的信息。这些部分相互关联，但不能彼此替代。
例如，迁移可能成功创建空表，随后应用显示登录页面。这仍不能证明文档、操作历史及文件已经迁移。也可能出现相反情况：数据已交付，但代码版本需要其他字段。此时，错误原因涉及各套材料的兼容性，并不一定是数据库缺失。
数据库之外还应检查哪些组件
- 导出内容。 架构、记录、序列、必要函数及其他对象；是否对所选表或时段作了限制。
- 版本。 数据库管理系统、扩展、应用运行环境及已固定的源代码版本。
- 用户与权限。 应用需要哪些角色，安装说明规定了哪些权限。
- 文件存储。 数据库所引用的已上传文档、图片及其他对象。
- 配置与依赖。 服务地址、任务队列、调度器、搜索索引及外部集成要求。
- 说明文档。 构建、恢复、启动和检查的步骤，以及允许使用的环境参数清单。
密钥等机密信息和生产密码不应出现在公开通信中，也不应与源代码一起公开发布。检验时，应协商通过安全方式移交必要信息，或在受控环境中进行检查。如果使用去标识化副本，需要说明替换了哪些信息，以及替换是否可能影响所检查的功能。
为何有SQL文件并不等于恢复成功
导出格式和参数很重要。例如，在PostgreSQL中，常规的单个数据库导出并不包含集群的全部共享对象：角色和表空间需要单独处理。仅导出架构不会包含用户记录。因此，归档大小或文件扩展名只能为交付内容提供初步线索。
恢复检查应考虑日志及操作是否完成。如果工具出错后仍继续运行，部分对象可能未被恢复。界面能够启动也不能替代数据检查。需要预先约定验证操作：打开特定文档、查找已知时段的记录、执行计算，或根据预期的原始信息生成报表。
如何在保留原始材料的同时开展核查
- 原样保存收到的整套材料，编制文件清单并记录接收情况。
- 另建工作副本用于检验，不要用其替换正在运行的生产系统。
- 记录测试环境特征，并与项目要求进行比对。
- 核查恢复说明、错误、警告及实际创建的对象。
- 执行约定场景，记录每一步的结果及输入数据。
- 单独列出修正或补充整套材料的操作，并检查这些操作对结果的影响。
在运行未知安装脚本和转储文件之前，需要对其内容及安全执行方式作技术评估。恢复应在访问受限的独立环境中进行。这也有助于区分交付材料自身的属性与现有服务器的特点；后者在交付后可能已积累新的变更。
如何描述发现的差异
与其笼统地说“数据库不能用”，不如准备表格，列明预期功能、初始条件、核查材料、操作顺序、实际结果及佐证日志。如果附件无法打开，不仅应检查数据库记录，还应检查相应文件是否存在、路径和访问权限。如果缺少历史记录，则应查明所交副本覆盖哪个时段。
每项结论都应对应材料的具体版本。添加新文件后成功启动，并不能自动说明最初交付的材料完整。同样，在不适用的服务器版本上出现故障，本身也不能证明所交代码存在缺陷。检验应明确呈现观察到相应结果时的条件。
应为鉴定人准备哪些材料
请提交技术任务书、交付清单、源代码归档或约定的代码仓库访问权限、收到的数据库副本、说明文档及错误消息。附上此前可运行或要求规定的场景清单，并说明依据。如果仍可访问原服务器，应提前约定如何固定其状态。
校验和有助于检查文件在存储和检验各阶段之间是否发生变化，但其本身不能证明作者、创建日期或整套材料是否符合合同。技术检验可依据所交材料查明组成、兼容性及运行的可复现性；评估合同后果则需要另行审查文件及争议情况。
检验问题
- 所交整套材料包含哪些软件组件和数据，为检查约定功能还缺少哪些材料？
- 源代码、数据库架构及所交数据的版本是否相互匹配？
- 能否按照所交说明，在技术任务书规定的环境中部署系统？
- 恢复及执行验证场景时出现哪些具体错误，其技术原因是什么？
- 要复现规定功能，还需要哪些额外组件或操作？