如何处理数据库字段和实体之间的命名关系

这里指的是二者之间的命名关系,以一些例子来说明:

1.用户表中有 用户名,任务名称,创建时间、更新时间等字段,那表中的列名就应该采用下划线并统一小写的形式: user_name,task_name, create_time,update_time

2.对应用户表的实体就采用规范的驼峰命名法一一对应即可:
userName、taskName、createTime、updateTime

3.这时候你可能会发现数据库有值,但查询结果的字段值为 null : 所以基于以上两个步骤,还需要在配置文件中设置开启 下划线转驼峰命名的配置:
mybatis:
configuration:
# 下划线转驼峰
map-underscore-to-camel-case: true

上述是以我自己的项目情况叙述,根据自己实际情况进行相应调整(欢迎补充指正)

### 数据库字段名实体类属性名对应规则 在Web项目中,为了保持代码的一致性可读性,通常会遵循一定的命名规范来定义数据库字段名对应的实体类属性名。当两者名称相同时,则无需额外注解;如果存在差异,则需通过特定机制确保数据映射正确。 #### 命名一致性情况 对于完全相同的命名情形,比如`user_name`作为数据库字段以及Java实体类中的`userName`,此时由于名字本身已经能够清晰表达含义并满足编程习惯的要求,因此不需要任何特殊处理即可实现自动匹配[^1]。 ```java public class User { private String userName; } ``` #### 不同命名场景下的解决方案 然而,在实际应用中经常会出现如下所示的不同步现象: - **驼峰式 vs 下划线风格** Java程序倾向于使用驼峰式的变量命名法(CamelCase),而SQL语句里的列名往往偏好于下划线分隔的形式(snake_case)。例如,`create_time`对应到Java端可能就是`createTime`这样的形式[^2]。 - **大小写敏感度区别** 某些数据库系统对大小写字母并不区分对待,但在面向对象的语言里这却是两个截然不同的标识符。所以即使逻辑上代表同一概念也可能因为字符集设定等因素造成无法直接关联的问题。 针对上述两种主要矛盾点,有几种常见的应对策略可供选择: ##### 使用框架内置特性 像MyBatis Plus这类ORM工具提供了便捷的功能选项——开启全局配置项`mapUnderscoreToCamelCase=true`之后便能自动化完成从下划线到驼峰转换的工作流程[^3]。 ```properties mybatis-plus.configuration.map-underscore-to-camel-case=true ``` ##### 显式声明映射关系 借助XML文件或者注解的方式来精确指明每一对应的数据成员间的关系。这种方式虽然较为繁琐但是灵活性极高,适用于复杂业务需求场合[^4]。 ```xml <resultMap type="com.example.Staff"> <id column="staff_id" property="id"/> <result column="join_date" property="joinDate"/> </resultMap> ``` ```java @TableField("dep_id") private Integer depId; ``` ##### 自定义命名处理器 还可以编写自定义的`NamingStrategy`接口实现类来自行控制如何将表/字段的名字转化为相应的模型结构描述[^5]。 ```java public class CustomNamingStrategy extends NamingStrategyStandard { @Override protected boolean isColumn(String name) { return super.isColumn(name); } // 更多重载方法... } ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值