MySQL 数据库名和表名区分大小写吗？

上周 我查了MySQL案例问题
Windows系统 默认不区分大小写
如database、DATABASE 由于 Windows 文件系统的原因，将被查看相同
NTFS不区分大小写
Linux系统 默认是区分
如database和Database 由于 Linux 文件系统的原因，将被视为两个名称 Ext4 和XFS是有区别的
但是MySQL有一个参数 lower_case_table_names
可以更改大小写规则
共有三个值
0：Linux默认 区分大小写
创建您想要的内容并保存您想要的内容 检查时必须完全相同
1 ：Windows 默认 不区分大小写
保存时转换为小写 搜索时不考虑大小写
2 ：特定于 Linux 创建时保留案例 检查时仍然被忽略
但是这个必须在初始化之前设置
实际建议 跨平台迁移 最好全部使用小写名称
更改 lower_case_table_names 时要小心 该参数要初始化才生效
如果修改得太晚，可能会出现问题
代码中引用的名称 风格要统一 避免资本和资本陷阱
简而言之 系统决定默认 参数可更改 但必须尽早做出改变

数据库的字段怎么命名

说实话，Access中的字段命名确实很让人头疼。
当我第一次接手一个老项目时，我几乎被乱七八糟的字段名称逼疯了。
这些以前的同事甚至不了解命名规则，这使得他们在后续询问时很难更改名字。

举个我最近遇到的例子。
有一个名为“Customer.Information.Details”的字段，我立即感到困惑 - 谁创建了这个？ 说实话，如果按照标准命名的话，应该叫“客户详细信息”或者“客户全名”，中间带点？ 这简直就是在数据库中埋下雷区。
后来我花了整整两天的时间把那些乱七八糟的表名和字段名都重命名了一遍，我才松了口气。

对于命名约定，我非常同意“中间最好不要加空格”的建议。
想一想，以后查询的话，还得在字段名两边加上引号。
这有多麻烦？ 比如要查“客户姓名”，就得写“客户姓名”，这就很别扭了。
我在给团队制定规则的时候，要求大家都用下划线代替空格，比如“Customer_name”，这样既清晰又不会影响查询。

对于那些字段类型，说实话，我平时用得最多的就是VARCHAR2 和DATE。
VARCHAR2 就足够了，但是 CHAR 不方便。
固定长度有时会浪费空间。
更不用说日期类型了。
虽然总说DATE格式有“千bug问题”，但是这么多年我遇到过一次吗？ 没有！ 所以您可以放心使用这个。

但是有件事要提醒你。
虽然LONG类型看起来很吓人，可以存储几GB的数据，但我实际上很少使用它。
想想看，Access 是一个损坏的系统。
一打开就冻结，存储了几GB的数据。
如果它不直接崩溃才奇怪。
我有一个客户之前尝试保存视频，但是系统直接卡在PPT中，所有数据都丢失了。
所以除非你必须保存一些大文档，否则不要碰LONG。

什么是RAW类型，二进制数据？ 说实话，我从事数据库十年来，这种需求只见过一次。
当时我正在保存电子签名。
我花了很长时间，最后还是以文本格式保存了。
这东西用得好就是神技，用不好就是负担。

简而言之，命名约定和字段类型既复杂又简单。
关键还是要看你的实际需求。
我建议你先弄清楚自己想做什么，然后就用它，不管别人怎么用。
比如我之前的项目中，客户想要保存客户评论时，我直接使用VARCHAR2 ，但他们坚持保存为LONG。
最终，系统崩溃，所有数据丢失。
你认为这不公平吗？

mysql数据库命名规则有哪些_mysql数据库命名规则详解

嘿...MySQL 的东西...仔细命名它。
当我刚开始的时候...我没有注意...我遇到了很多麻烦。

先说小写字母...这个很重要...不要用大写字母...比如：userdb...这在Windows和Linux下都可能有问题...我当时就掉进了这个陷阱...在Linux上跑得好好的...一切换到Windows...就出现各种错误...所以用小写字母...用下划线分隔...这是最基本的。

还有一个下划线来分隔...很多单词的组合...例如：order_history...这比orderhistory更容易阅读...尤其是当你要写SQL语句的时候...一起读...你可能会犯更少的错误。

不要使用保留字...顺序、组、用户...这些词不能使用...必须使用...只需将它们用引号括起来...但不要这样做...命名时请考虑一下...不要使用这些词。

长度...不要超过6 4 个字符...这是硬性规定...太长...管理起来会很麻烦...比如你写这个...this_is_a_very_long_database_name...这...不方便查询或修改。

特殊字符...空格、@、$...这些不能添加...容易出错...也可能被利用...不安全。

然后是前缀和后缀...例如，如果您有一个电子商务项目...用户表称为ecom_users...并且有一个教育项目...称为edu_users...这样您就可以区分...大项目...您必须这样做。

环境后缀...开发、测试、生产使用不同的后缀...比如开发环境叫user_db_dev...测试叫user_db_test...生产叫user_db_prod...这样...不容易混淆...尤其是测试的时候...可能会不小心删除生产数据...后果会很严重。

版本控制...数据库结构发生了变化...使用版本号来管理...例如：user_db_v1 、user_db_v2 ...这样...方便查看历史记录和恢复...
业务意识第一...表名、字段名...必须反映内容...比如Product_catalog、sales_data...不要用abc、xyz...这些...没人知道它们是什么。

项目大小...小项目...保持简单...示例：user_db...大项目...需要更复杂...添加前缀、后缀、版本号...示例：proj_a_order_db_v2 _prod。

团队协作...必须规范...定义一个文档...表名、字段名...一定要写清楚...比如user_login_log、order_create_time...不要让login_info、order_time...含糊不清。

命名不规范...风险高...可读性差...容易出错...难以管理...协作困难...安全风险...不要透露任何敏感信息...搬家很复杂...后悔来不及。

如何部署...代码审查...正在进行中审查...检查命名是否正确...自动化工具...使用脚本或SQLFluff...自动化测试...培训和文档...定期培训...标准文档模板...奖励机制...对遵守规则的人进行奖励...领导带头...项目负责人可以树立榜样...持续改进...随着项目的发展调整规则。

例如...电子商务平台...ecom_users、ecom_products、ecom_orders、ecom_ Payments...库存管理...ecom_inventory_v1 、ecom_inventory_v2 _test...
总之...命名MySQL...你必须认真对待...不要让混乱发生...它不可维护...后悔来不及了。

数据库表名的命名规范

表名规格：
全部小写字母和下划线。

模块信息格式。

名词或动宾短语。

不要使用缩写，使用完整的单词。

不超过三个字。

单数形式。

未使用关键字。

Sys_日志表前缀。

数据字典表前缀SD_或DT_。

例如：
user_order：用户订单表。

Sys_log：系统日志表。

user_role：用户角色关联表。

注意：
不要使用汉语拼音。

请勿使用大写字母。

创建表时添加描述。