这是我多年来整理的MYSQL建表规范 1.id要bigint(21)自增主键,就算每秒1w次insert操作,100年也用不完;而且数据是连续的,不像uuid插入的时候要找位置。 2.所有varchar和char等字符串类型的列默认为空字符串 '',有些建表软件上是Empty String,如果业务不允许为null,还要加上not null。 3.每个表都要有create_time(datatime类型,默认值:CURRENT_TIMESTAMP)和update_time(datatime类型,默认值:CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP)而且要加上索引。普通索引格式为idx_columnname1_columnname2(column_name1,column_name2),唯一索引格式为idx_columnname1_columnname2(column_name1,column_name2)。 4.布尔类型的字段要以is_开头 unsigned无符号修饰,注意实体类不需要is_前缀。 5.表和列加上COMMENT备注,时间长了就不知道是做啥的了。 6.备用字段一般从reserve1到reserve8,字段类型为varchar(255)。 7.不要使用mysql保留字做表、列、索引名,尽量用英文单词不要用拼音。 8.表和列的字符集要统一,关联查询的列要加上索引,并且字段类型和编码方式要一致,否则会导致索引失效。 9.联合索引建立:关联查询的列作为第一级索引,查询条件作为二级索引,查询时候使用联合索引效率更高。 10.自增属性AUTO_INCREMENT设置为1。 11.表上面设置完字符集和排序规则之后,列就不用单独设置了。 12.字段需要关联其它表查询的,要加上单索引 idx_columnname;业务上需要唯一的,加上唯一索引 udx_columnname。 13.表字符集默认设置为utf8mb4,支持特殊字符和表情符号。 14.建表语句的默认选项 ENGINE = InnoDB CHARACTER SET = utf8mb4 COLLATE = utf8mb4_general_ci,如果是主键自增的表 AUTO_INCREMENT = 1 行格式默认:ROW_FORMAT,不要单独设置。 15.字符类型列的长度除了备用字段,不要默认255,比如 company_id(36),如果使用UUID生成,32或36位就够了。
你好,个人建议: 1,数据库表名、字段名、索引名等都需要命名规范,可读性高(一般要求用英文),让别人一看命名,就知道这个字段表示什么意思。比如:account_number 2,选择合适的字段类型,比如 如果存储的字符串长度几乎相等,使用 char 定长字符串类型。 3,主键设计的话,最好不要与业务逻辑有所关联。有些业务上的字段,比如身份证,虽然是唯一的,一些开发者喜欢用它来做主键,但是不是很建议 4,每个表都需要添加这几个通用字段,如主键、create_time、modifed_time等 5,张表的字段不宜过多,一般尽量不要超过20个字段,一张表的字段过多,表中保存的数据可能就会很大,查询效率就会很低。 6,建表是需要选择存储引擎的,一般都选择INNODB存储引擎,除非读写比率小于1%, 才考虑使用MyISAM
简单的说:
1、1张表代表一个模型。
2、表里字段类型和长度合适,默认值合理。
3、添加索引增加查询效率。
数据库建表是数据库设计的一个关键环节,需要注意以下几个方面:
1、数据库范式
数据库设计时需要遵循数据库范式,以保证数据的一致性和有效性。常用的范式有第一范式(1NF)、第二范式(2NF)和第三范式(3NF)等。具体而言,就是要把数据分解成多个关系表,每个表只存储一个实体的信息,并通过外键关联起来。
2、数据类型和长度
在建表时需要选择合适的数据类型和长度。数据类型包括数值型、字符型、日期型等,长度则根据具体的业务需求来确定。需要注意的是,数据类型和长度的选择会影响数据库的性能和空间占用。
3、主键和索引
每个表需要有一个主键来唯一标识每条记录。主键通常是一个自增长的数字或者是一个具有唯一性的字段。此外,为了加快数据检索速度,还需要在一些常用的字段上建立索引,包括单列索引、组合索引等。
4、外键关系
在设计数据库时,如果存在两个或多个表之间存在关联关系,需要使用外键来建立表之间的联系。外键可以用来维护表之间的引用完整性,避免数据冗余和不一致性。
5、数据完整性
在建表时需要考虑数据完整性,包括唯一性约束、非空约束、默认值约束等。这些约束可以保证数据的正确性和一致性,避免出现数据异常和错误。
总之,在进行数据库建表时,需要充分考虑数据库范式、数据类型和长度、主键和索引、外键关系以及数据完整性等因素,以保证数据的一致性、完整性和有效性。
表的设计对于数据库的性能和数据管理起着至关重要的作用,以下是一些表建立的建议:
总之,一个好的表设计需要考虑到数据结构、数据类型、约束、索引、分区、数据完整性等多个因素,并尽可能的避免冗余数据和数据不一致的情况,从而提高数据库的性能和数据质量。
原始单据与实体之间的关系 1.表的设计有一对一、一对多、多对多的关系。大多数情况下表的设计为一对一关系:即一张原始单据对应且只对应一个实体。
主键与外键 1.主键与外键的设计,在全局数据库的设计中,占有重要地位。主键是实体的高度抽象,主键与外键的配对,表示实体之间的连接。
中间表、报表和临时表
绝大多数表单表列数保持在15个以内,如果你的字段超过15个,你应该考虑根据业务对表做垂直分表,数据拆分,这样既保证业务数据清晰,又能减轻单表读写压力 列数据选择正确的相关类型存储,如 int,char, varchar 建表时同时建立索引(当然视情况而定,有的表不需要建索引,就不要画蛇添足了), 避免上线后发现各种慢的问题再去建索引,这样直接影响线上业务,如果刚好需要建索引的表数据量大,且读写访问频繁,则很大几率直接导致服务宕机(线上环境你敢让服务宕机?),虽然可以通过其他工具或复制表的方式规避这个问题,但是如果开始就能建好,何必后面的这些麻烦呢 建大数据量表时,同时建立分区,例如按时间分区,按自增ID分区,避免上线后修改,影响线上业务,当然分区也只是一种方式,你也可以提前设计好分库分表模式或单库分表模式,这里分表指水平分表,垂直分表终究还是无法解决单表数据量大的问题,总之提前设计好,不然就是给自己或者后面来的人挖坑 列字段设置相关默认值,避免出现为(null, none)时,程序在对取出的数据做比较或判断时出现异常,而这个异常出现概率极低,导致测试也没发现(本人亲身经历,int字段默认为null, 取出的数据有些为数字,有些为null,导致测试环境程序没问题,线上环境出错)
一:字段的原子性
解释:保证每列的原子性,不可分解,意思表达要清楚,不能含糊,高度概括字段的含义,能用一个字段表达清楚的绝不使用第二个字段,必须要使用两个字段表达清楚的绝不能使用一个字段
二:主键设计
解释:主键不要与业务逻辑有所关联,最好是毫无意义的一串独立不重复的数字,常见的比如UUID或者将主键设置为Auto_increment;我们统一使用UUID
三:字段使用次数
解释:对于频繁修改的字段(一般是指状态类字段)最好用独立的数字或者单个字母去表示,不用使用汉字或长字符的英文
四:字段长度
解释:建表的时候,字段长度尽量要比实际业务的字段大3-5个字段左右(考虑到合理性和伸缩性),最好是2的n次方幂值。不能建比实际业务太大的字段长度(比如订单id如果考虑要业务增长的话,一定要使用Long型,对应的数据库的数据类型是bigint),这是因为如果字段长度过大,在进行查询的时候索引在B-Tree树上遍历会越耗费时间,从而查询的时间会越久;但是绝对不能建小,否则mysql数据会报错,程序会抛出异常;
五:关于外键
解释:尽量不要建立外键,保证每个表的独立性。如果非得保持一定的关系,最好是通过id进行关联,我们使用业务进行管理
六:动静分离
解释:最好做好静态表和动态表的分离。这里解释一下静态表和动态表的含义,静态表:存储着一些固定不变的资源,比如城市/地区名/国家(静态表一定要使用缓存)。动态表:一些频繁修改的表
七:关于code值
解释:使用数字码或者字母去代替实际的名字,也就是尽量把name转换为code,因为name可能会变(万一变化就会查询处多条数据,从而抛出错误),但是code一般是不会变化的.另一方面,code值存储的字符较少,也能减少数据库的存储空间的压力
八:关于Null值
解释:尽量不要有null值,有null值的话,数据库在进行索引的时候查询的时间更久,从而浪费更多的时间!可以在建表的时候设置一个默认值!
九:关于引擎的选择
解释:关于引擎的选择,innodb与myisam,myisam的实际查询速度要比innodb快,因为它不扫面全表,但是myisam不支持事务,没办法保证数据的Acid。选择哪个这就要看自己对于效率和数据稳定性方面的实际业务的取舍了
十:资源存储
解释:数据库不要存储任何资源文件,比如照片/视频/网站等,可以用文件路径/外链用
云数据库Mysql版兼容Mysql5.5、Mysql5.6、Mysql5.7、Mysql8.0,使用习惯和你在使用开源Mysql对应版本时是一致的,就是说过去你建表的习惯及规范在云数据Mysql版zhog中仍然适用。
您好,字段及表建议要有 COMMENT 主要出于这样做更有利于对共同开发或接手开发的其它同学。建立表及字段的 COMMENT 是一个天然的功能说明书。字段设置为非 NULL 更有利于语句查询,规避一些容易出现的问题,InnoDB 本身对 NULL 的处理有别于其它正常数据或空数据。字段类型注意要点:不建议使用ENUM,SET,原因在于不利于扩展,扩展变更表结构时会导致表阻塞写操作。VARCHAR长度的选择,以UTF8不超过2600字符,GBK不超过4000字符为最佳,在业务中推荐不过7000字符长度。不推荐使用BLOB,TEXT等大字段:主要原因在于大字段带来更多的IO,网络开销。
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。
阿里云关系型数据库主要有以下几种:RDS MySQL版、RDS PostgreSQL 版、RDS SQL Server 版、PolarDB MySQL版、PolarDB PostgreSQL 版、PolarDB分布式版 。