达梦SQL查询结果为何默认返回大写？

Question

在使用达梦数据库（DM8）进行SQL查询时，开发者常遇到一个问题：无论表名、字段名在定义时是否使用小写或双引号括起，查询结果集中的列名默认以大写形式返回。这导致在应用程序中通过列名获取值时需适配大写命名，增加了开发复杂度。该行为源于达梦数据库默认将未加双引号的标识符自动转换为大写存储和返回，符合其大小写不敏感的默认模式。如何正确处理标识符大小写以确保结果列名保持期望的大小写格式？

Answer 1

达梦数据库（DM8）SQL查询结果列名大小写处理深度解析

1. 问题背景与现象描述

在使用达梦数据库 DM8 进行开发时，许多开发者反馈：即使在建表语句中明确使用小写字母定义字段名，如 create table user_info (id int, name varchar(50));，执行 SELECT * FROM user_info; 后，返回结果集的列名仍为大写形式（如 "ID", "NAME"）。这导致在 Java、Python 等应用层通过列名访问数据时必须使用大写，违背了常见的命名规范（如驼峰命名法），增加了代码维护成本。

该行为的根本原因在于达梦数据库默认采用“大小写不敏感”模式，并将未用双引号包围的标识符自动转换为大写进行存储和返回。

2. 核心机制分析：标识符处理规则

达梦数据库遵循 SQL 标准中关于标识符的处理逻辑：

• 无引号标识符：如 name，会被系统自动转为大写，即视为 "NAME"。
• 双引号标识符：如 "name"，系统会严格保留其大小写格式。

这意味着，若希望列名以特定大小写形式出现在查询结果中，必须在 DDL 定义和 DML 查询中显式使用双引号。

3. 实际案例演示

建表方式	字段定义	查询结果列名	是否可保持小写
普通定义	name varchar(50)	NAME	否
带双引号	"name" varchar(50)	name	是
混合大小写	"userName" varchar(50)	userName	是
全大写引号	"UserName" varchar(50)	UserName	是

4. 解决方案路径对比

1. DDL 层面强制保留大小写：创建表时对字段名使用双引号。
2. 查询层面别名映射：通过 AS 子句指定期望的列名输出格式。
3. 应用层适配策略：统一转换列名为大写后再取值。
4. 驱动或 ORM 框架配置：利用 MyBatis、Hibernate 等框架的字段映射能力。
5. 修改数据库兼容模式：调整参数使数据库支持大小写敏感模式。

5. 推荐实践：DDL + 别名联合控制

以下为推荐的最佳实践示例：

-- 建表时使用双引号保留原始大小写
CREATE TABLE "UserInfo" (
  "userId" INT PRIMARY KEY,
  "userName" VARCHAR(100),
  "createTime" DATETIME
);

-- 查询时可通过别名进一步控制输出格式
SELECT 
  "userId" AS "userId",
  "userName" AS "userName",
  "createTime" AS "createTime"
FROM "UserInfo";

此方式确保元数据定义与结果输出一致，适用于需要精确控制 API 输出结构的场景。

6. 高级配置：启用大小写敏感模式

达梦数据库提供参数 case_sensitive 控制标识符比较行为。可通过以下步骤启用：

-- 查看当前设置
SELECT CASE_SENSITIVE FROM V$PARAMETER WHERE NAME = 'case_sensitive';

-- 修改初始化参数文件 dm.ini
CASE_SENSITIVE = 1

-- 重启数据库实例生效
-- 注意：此操作影响全局对象解析，需评估迁移风险

启用后，未加引号的标识符不再自动转为大写，但建议仍使用双引号以确保跨环境一致性。

7. 应用集成中的应对策略

graph TD
    A[应用程序发起查询] --> B{列名是否带引号?}
    B -- 是 --> C[返回原样大小写]
    B -- 否 --> D[返回大写列名]
    C --> E[直接按原名取值]
    D --> F[统一转大写后取值]
    E --> G[返回业务对象]
    F --> G

在 Spring Boot 或 Django 等框架中，可结合 RowMapper 或序列化器实现列名标准化处理，屏蔽底层差异。

8. 性能与维护考量

虽然使用双引号可以解决大小写问题，但也带来潜在副作用：

• SQL 语句编写更繁琐，易出错；
• 工具链兼容性下降（部分可视化工具无法识别带引号标识符）；
• 迁移至其他数据库时可能需重构；
• 索引、约束等对象命名也需同步处理。

因此，在团队协作项目中应制定统一的命名规范与编码指南。

9. 工具链支持现状

主流开发工具对达梦数据库的支持正在增强：

工具名称	是否支持引号标识符	智能提示	备注
DBeaver	部分	弱	需手动启用达梦插件
Navicat	是	强	商业版支持良好
达梦管理工具 DMC	是	强	官方推荐
IntelliJ IDEA	依赖 JDBC	中	配合 MyBatis 插件可用

10. 综合建议与长期规划

针对不同阶段的项目，提出如下建议：

• 新项目：从一开始就启用大小写敏感模式，并在 DDL 中使用双引号定义关键字段。
• 存量系统：通过视图封装旧表，对外暴露标准化的小写列名。
• 微服务架构：在 DAO 层统一做列名映射，避免扩散到上层逻辑。
• 跨库迁移准备：避免依赖特定数据库的大小写行为，提升可移植性。

最终目标是建立一套“定义即契约”的数据接口规范，减少运行时不确定性。