CREATE TABLE `idc_logistics_assign_rules` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键ID',
`sp_id` bigint(20) unsigned NOT NULL COMMENT '外键关联表ID',
`creator` varchar(255) NOT NULL COMMENT '创建人工号',
`gmt_create` datetime NOT NULL COMMENT '创建时间',
`modifier` varchar(255) NOT NULL COMMENT '修改人工号',
`gmt_modified` datetime NOT NULL COMMENT '修改时间',
`rule_name` varchar(255) NOT NULL COMMENT '规则名称',
`rule_json_val` varchar(4096) NOT NULL COMMENT '规则JSON字符串',
`rule_content` varchar(4096) NOT NULL COMMENT '规则中文描述',
`type` varchar(128) NOT NULL COMMENT '类型(同机房、同城、区域内、区域外、其他)',
`rule_lable` varchar(256) NOT NULL COMMENT '标签',
`is_valid` char(1) NOT NULL COMMENT '是否有效(y/n),默认n',
`is_deleted` char(1) NOT NULL COMMENT '是否删除',
`ordering` smallint(5) unsigned NOT NULL COMMENT '排序字段',
PRIMARY KEY (`id`),
UNIQUE KEY `uk_ordering` (`ordering`),
KEY `idx_rule_content` (`rule_content`(255))
) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=utf8 COMMENT='表名';
上面是建表的SQL语句,对于其中的数据类型有不明白的地方,如下:
1.smallint(5),我看了smallint本来的范围是:
A smallint is between -32768 and 32767 signed, or 0 and 65535 unsigned.
但是加了smallint(5)之后,对它的范围并没有影响,那么加这个有什么用呢?。假如我不指定括号中的位数呢?它的默认值是要取什么值呢?
2.同理varchar(255)是表示255个字节么?如果要存中文的话,用utf8编码,算上标点符号,大概能存多少个中文汉字呢?
3.另外还有datetime这种数据类型,一般并不指定有效位数的。那么如果我要精确到秒的、精确的分的、精确到月的,数据库中是不能直接这么存的么?只能存一个完整的时间(存一个以1970开始的long型方便),然后查的时候,可以用Mysql提供的函数来过滤??
======================================================================
在列中使用zerofill,如插入int(4),你插入1,显示0001,你插入55555,显示也是55555,插入负数显示为0000,因为mysql自动增加UNSIGNED属性 UNSIGNED不能为负数,当你插入负数时就显示0, 多操作就能理解 希望采纳
1 smallint,int,等你设定长度和不设定长度是没有任何区别的
2 utf8 255/3 gbk 255/2
3 一般时间都存的时间戳,FROM_UNIXTIME(unix_timestamp,format) mysql自带的 时间戳转时间,可以满足你的需求
类似int这种的是字节括号后面的没影响;
类似char这种的是字符,括号里限定的就是字符长度
1-整齐好看
2-大概是255/3吧,没太仔细研究过
3-通常是都是bigint的时间戳或者timestamp/datetime类型,输出的时候php可以格式化输出,不需要mysql这边处理。
1.smallint默认值是6,因为符号位。对范围没有影响,该怎么显示怎么显示,但是你在SMALLINT(3) 后面加上ZEROFILL就可以看出两者的差别了
2.varchar(255)表示255个字符,不是字节,这个你可以实验一下,不过也有人说老版本是字节。如果是字符的话就可以存255个中文了,字节就是255/3,因为一个中文是一个字符,而一个字符在UTF8里面算3个字节。
3.这个主要还是你后台对时间进行分割处理,可以多加几个年月日时分秒的字段。当然mysql也是有函数可以处理的,如:HOUR(time),SECOND(time),MONTH(time)
1、正如其他人所说,括号里面的数字只是补位数字,对该字段所表示的取值范围并没影响,这个补位的数字只有当你设置该字段为zerofill的时候才会体现差别;
2、这个自己做个小测试就好了,下面会说;
3、如果数据量大且日期字段是查询条件之一,那用时间戳存储会比较好,通杀,否则按需使用
date
,datetime
和timestamp
,又或者按需增加年(smallint
)、月(tinyint
)、日(tinyint
)等字段;date
,datetime
和timestamp
,又或者按需增加年(smallint
)、月(tinyint
)、日(tinyint
)等字段;关于问题1和2,我新建了一个表做了个测试,如下:
结果:
但以下这个行为将会依赖
sql_mode
的设置,例如:写入一条记录,其中b值的长度为11,
在我本地的一个数据库是可以写入并且没有报错的,但存储的数据是
关于问题1和2,我新建了一个表做了个测试,如下:一二三四五六七八九零
,也就是说会把超过10位的数据抹掉;但在我本地的另一个数据库却发现报错了,报
Data too long for column 'b' at row 1
。通过
SELECT @@sql_mode;
发现,后者多了一个STRICT_TRANS_TABLES
rrreee
结果:🎜 rrreee 🎜但以下这个行为将会依赖sql_mode
的设置,例如:🎜写入一条记录,其中b值的长度为11,🎜 rrreee 🎜在我本地的一个数据库是可以写入并且没有报错的,但存储的数据是一二三四五六七八九零
,也就是说会把超过10位的数据抹掉;🎜但在我本地的另一个数据库却发现报错了,报Data too long for column 'b' at row 1
。🎜通过SELECT @@sql_mode;
发现,后者多了一个STRICT_TRANS_TABLES
,导致当尝试写入不合乎ddl定义的数据时会报错。🎜 🎜参考资料:https://dev.mysql.com/doc/ref...🎜