mysql9 字段 驼峰命名

从MySQL 8 .0开始，支持驼峰命名，但需要注意规则。
我之前在2 02 2 年做过一个项目，使用MySQL 8 .0，字段名称使用驼峰式大小写，例如UserName。
语法允许，MySQL标识符支持字母数字下划线，大小写没有限制。

但这取决于 lower_case_table_names 系统变量。
如果设置为 0，则区分大小写。
我当时是Linux系统，默认是0，所以字段名必须完全匹配，不能写错。
例如，如果表名称为 UsersTable，则查询应编写为 UsersTable。
如果写成用户表的话是找不到的。
如果设置为1 或2 ，则会自动转换为小写并存储。
查询不区分大小写。
也可以通过写usertable来找到UsersTable。

开发时需要关注ORM框架。
与MyBatis和SpringDataJPA一样，驼峰式大小写默认可以转换为下划线。
例如，如果您的字段名称是 UserName，则默认情况下它可能会映射到 user_name。
我需要在 MyBatis 中添加 @Table 和 @Column 注解来指定字段名称。
否则，你将无法得到正确的结果，并且在搜索数据时你会感到困惑。

编写SQL语句时也需要小心。
字段名称区分大小写，lower_case_table_names 为 0，因此必须用引号引起来。
例如，从 UsersTable 中选择用户名。
否则会被认为是小写而找不到。
建议统一命名风格。
后来我在所有项目中都使用了下划线以避免出现问题。

MySQL9 预览版（2 02 4 ），驼峰式命名没有做大的调整，还是老逻辑。
主要优化是针对性能、JSON支持等，与命名无关。

总结一下，MySQL支持camelback，但是建议生产环境使用统一的风格，以减少问题。
使用驼峰式大小写时，您需要确保 lower_case_table_names 配置与 ORM 代码匹配。
复杂的场景需要有与之相关的反引号或 ORM，否则如果你做得不对就会遇到麻烦。

调度工具（ETL+任务流）

哦，让我告诉你关于 Kettle 和 Oozie 的事。
我在阿里巴巴工作的时候，数据抽取项目中使用了Kettle，数据仓库中的调度使用了Oozie。
水壶其实就是水壶。
您可以将各种数据放入其中，并以您设置的格式转储出来。
记得有一年，我们参与一个电商平台的数据同步。
数据量很大，我们每天运行一次。
我们依靠kettle来提取淘宝的数据，将其转换为我们Hive需要的格式，然后转储到HDFS中。
那时候配置水壶真是一件头疼的事，各种各样的问题，半夜醒来看日志也很正常。

oozie 是一个工作流程。
与水壶相比，oozie 更像是一个指挥官，告诉你何时该做什么。
例如，我们有一个项目需要每天清晨运行复杂的 ETL 流程。
这个过程可能包括一些水壶工作，并且必须与 Hadoop 的 MapReduce 交互。
当时，我们使用oozie来定义这个工作流程，指定这些作业的执行顺序以及依赖关系。
记得有一次，水壶的工作卡住了，但oozie没有注意到，导致整个进度暂停。
实在是太震撼了。

让我告诉你有关 sqoop 的事情。
这有什么作用呢？即将关系数据库中的数据导入 HDFS。
在京东的时候，我负责一个大数据平台，使用sqoop将订单数据从MySQL导入到HDFS。
我记得有一年，当我们导入数据时没有指定目标目录，结果默认转到/user/root/。
随着数据量的增加，硬盘几乎无法容纳它。
还有一次我们用sqoop增量输入，参数出错了。
结果，所有数据均已导入。
实在是让人哭笑不得。

最后说一下我用过的调度工具oozie和azkaban。
Oozie 功能齐全，但配置复杂。
在百度期间，我使用 oozie 来调度数据仓库并定义工作流程。
编写 XML 文件对我来说是一件头疼的事。
至于azkaban，它是轻量级且易于配置的。
我们有一个小项目，经常使用 azkaban 做一些与 Kettle 相关的工作。
它非常简单且易于使用。
然而oozie和azkaban都有一个问题，那就是时区。
我在网易的时候，用oozie整理工作，发现时间不对。
查了一下，原来是时区问题，真是烦人。

总之，kettle、oozie、sqoop都是好东西，但是使用起来都有坑。
如果您有任何具体问题，我会详细向您解释。