17模板网站,数字营销传播,网站营销策略组合,宿迁网站建设推广公司阿丹#xff1a; 国庆快乐呀大家#xff01; 在项目开始前一个好的设计、一个健康的表关系#xff0c;不仅会让开发变的有趣舒服#xff0c;也会在后期的维护和升级迭代中让系统不断的成长。那么今天就认识和解读一下阿里的准则#xff01;#xff01;
建表规约
表达是…阿丹 国庆快乐呀大家 在项目开始前一个好的设计、一个健康的表关系不仅会让开发变的有趣舒服也会在后期的维护和升级迭代中让系统不断的成长。那么今天就认识和解读一下阿里的准则
建表规约
表达是与否概念的字段
原文 【强制】表达是与否概念的字段必须使用 is_xxx 的方式命名数据类型是 unsigned tinyint 1 表示是 0 表示否。 说明 任何字段如果为非负数必须是 unsigned 。 注意 POJO 类中的任何布尔类型的变量都不要加 is 前缀所以需要在 resultMap 设置 从 is_xxx 到 Xxx 的映射关系。数据库表示是与否的值使用 tinyint 类型坚持 is_xxx 的 命名方式是为了明确其取值含义与取值范围。 正例 表达逻辑删除的字段名 is_deleted 1 表示删除 0 表示未删除。 阿丹
如果使用这个准则可以避免以下情况的问题
命名混淆通过使用明确的命名规则可以确保代码中的字段名清晰易懂减少阅读和理解代码的困难。类型不匹配由于强制规定了字段类型为unsigned tinyint可以确保字段值在数据库中正确存储和传输避免了因类型不匹配而引起的错误。范围不确定通过使用tinyint类型并明确是与否的取值范围可以确保字段值的合理取值范围避免超出数据类型的范围而引发的错误。逻辑错误采用is_xxx的命名方式与数据库中常用的布尔类型字段命名规范保持一致有助于避免在查询、筛选等操作中出现的逻辑错误。代码可维护性统一的命名规则使得代码更易于维护其他开发人员在阅读或接手项目时可以快速理解并遵循该规则降低了代码维护的难度。
综上所述通过遵循该准则可以避免由于命名混淆、类型不匹配、范围不确定、逻辑错误以及代码可维护性差引起的问题。
表名、字段名
原文 【强制】表名、字段名必须使用小写字母或数字 禁止出现数字开头禁止两个下划线中间只 出现数字。数据库字段名的修改代价很大因为无法进行预发布所以字段名称需要慎重考虑。 说明 MySQL 在 Windows 下不区分大小写但在 Linux 下默认是区分大小写。因此数据库名、 表名、字段名都不允许出现任何大写字母避免节外生枝。 正例 aliyun _ admin rdc _ config level 3_ name 反例 AliyunAdmin rdcConfig level _3_ name 阿丹
遵循这个准则可以避免以下情况的问题
大小写问题在Windows系统中MySQL不区分大小写但在Linux系统中默认是区分大小写的。因此遵循这个准则可以避免在跨平台使用时出现大小写引起的混乱或错误。数字开头问题禁止表名和字段名以数字开头可以避免在查询和引用时出现不必要的困扰和错误。双下划线命名问题禁止两个下划线之间只出现数字可以避免与数据库保留字或特殊字符引起的冲突让名称更具可读性和可理解性。命名规范一致性通过正例示例可以了解到符合规范的表名、字段名命名方式从而保持代码风格的一致性降低代码维护的难度。
遵循这个准则可以帮助避免在数据库表名和字段名命名时出现不规范、不可读、易混淆等问题提高代码的可维护性和可读性。
表名不使用复数名词
原文 【强制】表名不使用复数名词。 说明 表名应该仅仅表示表里面的实体内容不应该表示实体数量对应于 DO 类名也是单数 形式符合表达习惯。 阿丹
如果遵循这个准则可以避免以下情况的问题
名词复数问题在表名中不使用复数名词可以避免混淆表中的实体与实体的数量。例如如果你有一个users表它应该只包含user实体而不是users实体保持单数形式能够清晰地区分实体和实体的数量。数据一致性问题在数据存储和处理过程中如果表名使用复数名词可能会导致数据处理的一致性问题。例如在查询或过滤数据时可能会因为忽略了复数形式而导致数据的不一致。代码可读性问题表名和DO类名使用单数形式可以使代码更加易读和理解。在代码中引用表或类的名称时单数形式可以更清晰地表达其含义减少阅读和理解代码的难度。
遵循这个准则可以帮助避免在表名和DO类名中使用复数名词提高代码的可读性和数据的一致性使代码更加规范和易于维护。
禁用保留字
原文
【强制】禁用保留字如 desc、range、match、delayed 等请参考 MySQL 官方保留字。 阿丹
遵循这个准则你可以避免以下情况的问题
数据库表或字段命名问题MySQL有官方定义的保留字如desc、range、match等。如果你在创建表或定义字段时使用了这些保留字可能会导致语法错误或运行时问题。因此遵循这个准则可以避免此类问题。查询语句错误在编写查询语句时如果使用了MySQL的保留字作为表名或字段名可能会导致查询失败或返回错误结果。遵循这个准则可以避免此类问题。代码可读性和可维护性使用保留字作为表名或字段名可能会对代码的可读性和可维护性造成负面影响因为其他开发人员可能不熟悉或理解错误的命名。遵循这个准则可以提高代码的可读性和可维护性。
主键索引名为 pk_字段名
原文 【强制】主键索引名为 pk_ 字段名唯一索引名为 uk _ 字段名 普通索引名则为 idx _ 字段名。 说明 pk_ 即 primary key uk _ 即 unique key idx _ 即 index 的简称。 阿丹
如果遵循这个准则可以避免以下情况的问题
索引命名混淆通过使用特定的前缀如 pk_uk_idx_来区分主键索引、唯一索引和普通索引可以使代码更具可读性并减少对索引的误解和误用。维护和扩展困难在代码中明确指定不同类型的索引名称有助于降低后期维护和扩展的难度。当需要添加新的索引或修改现有的索引时可以通过查看索引名称的前缀来快速识别其类型从而更容易进行维护。命名规范一致性遵循这种命名规范可以使你的代码与阿里巴巴Java开发手册保持一致从而提高代码的可读性和可维护性。同时也可以减少在团队合作或代码审查过程中的争议和沟通成本。便于工具的使用一些开发工具如IDE或数据库管理工具可以自动识别或解析特定的命名规则从而方便开发者进行索引的创建、查询和维护。遵循这种命名规范可以使你的代码更好地与这些工具集成提高开发效率。
遵循这个准则可以帮助你避免在索引命名时出现混淆、误用等问题并提高代码的可读性、可维护性和可扩展性。
小数类型为 decimal
原文 【强制】小数类型为 decimal 禁止使用 float 和 double 。 说明 float 和 double 在存储的时候存在精度损失的问题很可能在值的比较时得到不 正确的结果。如果存储的数据范围超过 decimal 的范围建议将数据拆成整数和小数分开存储。 阿丹
精度损失问题float和double类型在存储时存在精度损失的问题。特别是在进行浮点数比较时可能会得到不准确的结果。使用decimal类型可以避免这种精度损失因为它采用了十进制表示法能够更准确地存储和比较小数。数据存储问题如果需要存储的数据范围超过了decimal的范围按照这个准则的建议可以将数据拆分成整数和小数部分然后分别存储。这样可以避免数据存储问题确保数据的完整性和准确性。代码可维护性和可读性使用decimal类型可以使代码更具可维护性和可读性。因为其他开发人员可以更容易地理解你的代码并清楚地知道你正在使用的数据类型。
如果存储的字符串长度几乎相等使用 char 定长字符串类型
原文 【强制】如果存储的字符串长度几乎相等使用 char 定长字符串类型。 阿丹
可以避免以下情况的问题
内存浪费在MySQL中如果存储的字符串长度几乎相等使用char定长字符串类型可以避免内存浪费。因为char类型是定长的它不会像变长字符串类型那样在内存中分配额外的空间。性能问题使用char定长字符串类型可以提高性能。由于char类型是定长的所以在执行字符串拼接或频繁修改字符串等操作时它不会像变长字符串类型那样需要重新分配和复制内存因此性能更高。减少垃圾回收的压力由于char定长字符串类型不会像变长字符串类型那样产生内存重新分配和复制因此可以减少垃圾回收的压力降低系统的开销。避免可能的溢出问题对于某些特定场景如字符串拼接等操作使用char[]可能比String更安全因为它不会因为创建新的字符串实例而引发可能的溢出问题。
varchar 是可变长字符串不预先分配存储空间
原文 【强制】 varchar 是可变长字符串不预先分配存储空间长度不要超过 5000 如果存储长 度大于此值定义字段类型为 text 独立出来一张表用主键来对应避免影响其它字段索 引效率。 阿丹
这段阿里巴巴的Java MySQL开发准则强调了如何有效地使用数据库中的字符串字段。下面是我对这段准则的理解以及使用这个准则可以避免的情况
使用 VARCHAR 而不是固定长度的字符串类型 (CHAR) 可以避免预先分配存储空间的问题。VARCHAR 是可变长度的字符串只会存储实际的数据不会像 CHAR 那样预先分配空间。这可以节省存储空间特别是在处理长度不定的字符串时。这段准则建议将 VARCHAR 的最大长度设置为5000。这是因为在大多数情况下如果字符串的长度超过这个值那么将其定义为 TEXT 类型可能更为合适。TEXT 类型适用于存储大量的文本数据可以很好地处理大量文字内容。如果一个字段的长度超过了5000准则建议将这个字段独立出来放到另一张表中并使用主键来对应。这可以避免这个大字段影响其他字段的索引效率。在数据库中索引是提高查询速度的关键如果一个字段非常大可能会影响到其他字段的索引效率。通过将大字段独立出来可以避免这种情况。这个准则还可以避免在处理大量文本数据时出现的性能问题。如果一个字段的长度非常大可能会影响到查询速度和数据库的性能。通过将大字段独立出来可以减少对数据库性能的影响。
表必备三字段
原文 【强制】表必备三字段 id , gmt _ create , gmt _ modified 。 说明 其中 id 必为主键类型为 bigint unsigned 、单表时自增、步长为 1 。 gmt_create, gmt_modified 的类型均为 datetime 类型前者现在时表示主动创建后者过去分词表示被 动更新。 阿丹
这条准则的建议是每一个数据库表都应该有以下三个字段
id这是一个唯一标识符通常被用作主键。在这个字段中你应该存储的是每个记录的唯一标识。在阿里巴巴的准则中推荐使用bigint unsigned类型这意味着这个数字可以被视为非常大的无符号整数。在单表情况下这个字段通常被设置为自增即每当你添加一条新的记录时这个字段的值会自动增加。gmt_create这是一个日期时间字段用于记录每条记录的创建时间。它的类型是datetime可以精确到秒。在这个字段中你可以存储创建记录时的日期和时间。gmt_modified这是另一个日期时间字段用于记录每条记录最后一次被修改的时间。它的类型也是datetime。在这个字段中你可以存储对记录进行最后一次修改时的日期和时间。
如果你遵循这个准则你可以避免以下情况的问题
每个表都有唯一的主键可以避免数据重复的问题。特别是在处理大量数据时主键可以确保数据的唯一性和准确性。gmt_create 和 gmt_modified 这两个时间戳字段可以帮助你跟踪记录的创建和修改历史可以避免在处理数据时出现时间上的混乱。使用这些标准字段可以让你更容易地实现数据库操作的可追溯性和可管理性。例如你可以很容易地找出最近被修改的记录或者找到某个特定时间点创建的记录等。这些字段的定义和使用也有助于提高查询性能因为数据库可以更有效地使用这些字段进行索引。
总的来说这个准则有助于在设计数据库表结构时更加规范和统一以便于进行更高效的数据管理和查询操作避免了可能的数据问题。 业务名称_表的作用 原文 【推荐】表的命名最好是加上 “ 业务名称 _ 表的作用 ” 。 正例 alipay _ task / force _ project / trade _ config 阿丹 这段阿里巴巴的Java MySQL开发准则建议你在命名表时采用“业务名称_表的作用”的形式以增加可读性和可理解性。这种命名方式可以帮助开发者更好地理解表在业务逻辑中的位置和作用有利于维护和扩展代码。 以正例中的例子来说明 alipay_task这个表可能涉及到支付宝的相关任务信息通过这样的命名我们可以直观地知道这个表的内容与支付宝相关并且是用来存储任务信息的。force_project这个表可能涉及到强制项目相关的信息如此命名可以帮助我们理解这个表主要存储的是关于强制项目的数据。trade_config这个表可能存储的是交易配置的相关信息通过这个命名我们可以清楚地知道这个表的主要作用是存储交易配置。 如果你遵循这个准则你可以避免以下情况的问题 减少歧义明确的表名可以避免开发和维护过程中对表的理解产生歧义。如果表名与其代表的数据内容不一致可能会导致数据管理混乱或理解错误。提高代码可读性清晰的表名可以让其他开发者更容易理解代码减少阅读和理解代码的难度。易于维护和扩展明确的表名使得在项目后期扩展和维护时更加方便。例如如果需要添加新的表使用相似的命名方式可以让其他开发者更快地理解新表的作用。避免数据冗余如果表的命名能明确其作用可以避免因冗余数据造成的存储空间浪费和查询效率降低。便于数据库管理对于大型项目或复杂的数据库结构命名的统一性和规范性可以使数据库管理更为高效。 总的来说这个准则可以提高代码的可读性和可维护性避免因表命名不当引发的一系列问题。 字段允许适当冗余 原文 【推荐】字段允许适当冗余以提高查询性能但必须考虑数据一致。冗余字段应遵循 1 不是频繁修改的字段。 2 不是 varchar 超长字段更不能是 text 字段。 正例 商品类目名称使用频率高字段长度短名称基本一成不变可在相关联的表中冗余存 储类目名称避免关联查询。 阿丹 这段阿里巴巴的Java MySQL开发准则是在推荐一种适当的冗余策略来提高查询性能但同时也强调了数据一致性的重要性。这里的冗余字段应该遵循以下两个原则 不是频繁修改的字段如果一个字段经常被修改例如用户名、描述等那么冗余这个字段可能会导致数据不一致。因为每次修改都需要更新所有相关的冗余字段这可能导致数据不一致或者数据不一致的问题更严重。不是超长varchar字段更不能是text字段varchar字段长度过长或者使用text字段可能会导致存储冗余数据过多从而影响到数据库的性能。同时过长的字段也可能会占用更多的内存和磁盘空间导致资源的浪费。 举个正例比如商品类目名称这个字段如果使用频率高字段长度短即类目名称基本一成不变那么可以在相关联的表中冗余存储这个类目名称以避免每次需要用到它时都要进行一次关联查询。 如果你遵循了这条准则你可以避免以下情况的问题 提高查询性能通过适当的冗余策略可以提高查询性能特别是对于一些复杂的关联查询冗余可以减少关联查询的复杂度提高查询效率。减少资源消耗通过冗余策略可以减少关联查询的使用从而减少数据库的资源消耗提高数据库的性能和稳定性。避免数据不一致遵循准则中的两个原则可以避免因为频繁修改和冗余字段过长而引起的数据不一致问题。提高数据安全性冗余策略可以提高数据的可用性和可靠性减少因为查询失败或者数据丢失而带来的风险。 单表行数超过 500 万行或者单表容量超过 2GB才推荐进行分库分表 原文 【推荐】单表行数超过 500 万行或者单表容量超过 2 GB 才推荐进行分库分表。 说明 如果预计三年后的数据量根本达不到这个级别请不要在创建表时就分库分表。 阿丹 这段阿里巴巴的Java MySQL开发准则是在推荐一种数据库设计的策略即当单表行数超过500万行或者单表容量超过2GB时推荐进行分库分表。 首先我们需要理解什么是分库分表。分库分表是一种数据库设计策略它用于解决单个数据库无法处理大量数据的问题。通过将一个大的表拆分成多个小的表并分布在不同的数据库分库或者不同的表分表中可以提高查询性能和数据管理。 那么这段准则在说什么呢这段准则的意思是如果一个表的容量或者行数还没有达到这个级别那么就没有必要过早地进行分库分表。过早地进行分库分表可能会带来一些额外的复杂性例如需要处理跨表查询数据一致性问题以及可能的分布式事务等问题。而这些问题的处理往往会带来额外的开发难度和性能损耗。 所以如果预计三年后的数据量根本达不到这个级别那么在创建表时就不应该过早地考虑分库分表。 通过遵循这个准则你可以避免以下情况 过早地引入复杂性如果没有必要进行分库分表那么你可以避免引入这种架构带来的复杂性。例如你可以避免处理跨表查询数据一致性问题等。避免浪费资源如果没有必要进行分库分表那么你可以避免在这种场景下投入大量资源来设计和实现分库分表的方案。这些资源可能会被更好地用于其他方面例如业务功能的开发等。避免性能下降虽然分库分表可以提高查询性能但是如果过早地引入这种架构可能会导致性能下降。例如跨表查询可能会导致性能下降数据一致性问题可能会导致数据更新操作性能下降等。 总的来说这个准则可以帮助你在数据库设计时避免过早地引入复杂性浪费资源以及性能下降等问题。 合适的字符存储长度 原文 【参考】合适的字符存储长度不但节约数据库表空间、节约索引存储更重要的是提升检 索速度。 正例 如下表其中无符号值可以避免误存负数且扩大了表示范围。 阿丹 这段阿里巴巴的Java MySQL开发准则主要强调了合适字符存储长度的选择对于数据库性能的重要影响。 对于字符存储长度来说不同的数据类型有不同的存储长度。例如tinyint是1字节smallint是2字节int是4字节bigint是8字节。这些长度不仅决定了存储空间的大小也影响了索引的存储以及查询的速度。 当我们在设计数据库表的时候要尽可能地选择合适的字符存储长度。如果选择的长度过大可能会造成存储空间的浪费而如果选择的长度过小可能会存储不了足够的数据或者造成数据溢出。 选择正确的字符存储长度可以帮助我们避免以下情况 节约数据库表空间选择正确的字符存储长度可以有效地利用存储空间避免空间的浪费。提高检索速度如果字符存储长度合适那么在执行查询操作时数据库可以更快地定位到所需的数据从而提高检索速度。减少索引存储索引是用于快速查找数据的如果字符存储长度合适那么索引的大小也会相应地减小从而减少存储空间的使用。避免数据溢出如果字符存储长度过小可能会导致数据溢出即数据会被写入到无法正常读取的内存区域从而造成数据丢失。 此外这段准则还给出了一些具体的例子说明了如何选择合适的字符存储长度。例如对于人的年龄选择tinyint unsigned就足够了因为人的年龄一般不会超过255岁而对于龟的年龄选择smallint unsigned更合适因为龟的寿命一般在数百岁以内其值的范围在0到65535之间对于恐龙化石和太阳的年龄则分别选择了int unsigned和bigint unsigned因为它们的年龄范围更大。 通过遵循这个准则你可以在设计数据库表时选择合适的字符存储长度从而避免上述问题。 以上就是mysql数据库的建表规约以及阿丹的解读希望大家在设计表的时候可以先按照这样的规则思考一番另外建表一定一定要慎重再次祝大家国庆节快乐
