MySQL数据库设计SQL规范

1 命名规范

1、库名、表名、字段名必须使用小写字母并采用下划线分割；

2、库名、表名、字段名支持最多32个字符，易于辨识以及减少传输量不要超过32；

3、库名、表名、字段名禁止使用MySQL保留关键字；

4、临时库、临时表名必须以tmp为前缀并以日期为后缀；

5、备份库、备份表名必须以bak为前缀并以日期为后缀；

----------------------------------------------------------------

2 基本规范

1、使用INNODB存储引擎

5.5以后的默认引擘，支持事务，行级锁，更好的恢复性，高并发下性能更好，对多核，大内存，ssd等硬件支持更好；

2、表字符集使用UTF8

使用utf8字符集，如果是汉字，占3个字节，但ASCII码字符还是1个字节；统一，不会有转换产生乱码风险；

3、所有表都需要添加注释；

4、不在数据库中存储图片、文件等大数据；

5、禁止在线上做数据库压力测试；

6、禁止从测试、开发环境直连线上数据库；

-----------------------------------------------------------------

3 库表设计规范

1、尽量避免使用分区表

MySQL的分区表实际性能不是很好。

2、拆分大字段和访问频率低的字段，分离冷热数据

3、采用合理的分库分表策略，推荐使用HASH进行分表，表名后缀使用十进制数，下标从0开始

首次分表尽量多的分，避免二次分表，二次分表的难度和成本较高

4、按日期时间分表需符合YYYY[MM][DD][HH]格式

5、单表字段数控制在20个以内

6、一条完整的建表语句中应包含必要的字段、主键、合理的索引（综合代码中所有的条件语句创建合理的索引，主键必须要有）

-------------------------------------------------------------------

4 索引设计规范

索引是一把双刃剑，它可以提高查询效率但也会降低插入和更新的速度并占用磁盘空间

1、单张表中索引数量不超过5个；

2、单个索引中的字段数不超过5个；

对字符串使用前缀索引，前缀索引长度不超过10个字符；如果有一个CHAR(200)列，如果在前10个字符内，多数值是惟一的，那么就不要对整个列进行索引。对前10个字符进行索引能够节省大量索引空间，也可能会使查询更快；

3、表必须有主键，不使用UUID、MD5、HASH作为主键，尽量不选择字符串列作为主键；主键建议选择自增id；

4、创建复合索引时区分度较大的字段放在最前面；不在低区分度的字段上创建索引，例如“性别”；

5、避免冗余或重复索引

合理创建联合索引（避免冗余），index(a、b、c)相当于index(a)、index(a、b)、index(a、、b、c)；

6、索引不是越多越好，按实际需要进行创建

每个额外的索引都要占用额外的磁盘空间，并降低写操作的性能

7、不在索引列进行数学运算和函数运算；

8、尽量不要使用外键

外键用来保护参照完整性，可在业务端实现，对父表和子表的操作会相互影响，降低可用性；

9、不使用%前导的查询，如like“%xxx”，无法使用索引；

10、不使用反向查询，如not in / not like

无法使用索引，导致全表扫描

全表扫描导致buffer pool利用降低

---------------------------------------------------------------

5 字段设计规范

1、尽可能不要使用TEXT、BLOB类型

删除这种值会在数据表中留下很大的"空洞"，可以考虑把BLOB或TEXT列分离到单独的表中

2、用DECIMAL代替FLOAT和DOUBLE存储精确浮点数

浮点数相对于定点数的优点是在长度一定的情况下，浮点数能够表示更大的数据范围；浮点数的缺点是会引起精度问题

3、将字符转化为数字

4、使用TINYINT来代替ENUM类型

5、字段长度尽量按实际需要进行分配，不要随意分配一个很大的容量

VARCHAR(N)，N表示的是字符数不是字节数，比如VARCHAR(255)，可以最大可存储255个汉字，需要根据实际的宽度来选择N；

VARCHAR(N)，N尽可能小，因为MySQL一个表中所有的VARCHAR字段最大长度是65535个字节，进行排序和创建临时表一类的内存操作时，会使用N的长度申请内存；

6、如果可能的话所有字段均定义为not null

7、使用UNSIGNED存储非负整数

同样的字节数，存储的数值范围更大。如tinyint有符号为-128-127，无符号为0-255 8、使用TIMESTAMP存储时间. 因为TIMESTAMP使用4字节，DATETIME使用8个字节,同时TIMESTAMP具有自动赋值以及自动更新的特性.

9、使用INT UNSIGNED存储IPV4

10、使用VARBINARY存储大小写敏感的变长字符串

11、禁止在数据库中存储明文密码

-------------------------------------------------------------------

6 SQL设计规范

1、使用预编译语句prepared statement

只传参数，比传递SQL语句更高效，一次解析，多次使用，降低SQL注入概率

2、尽量避免相同语句由于书写格式的不同，而导致多次语法分析

3、避免隐式转换

会导致索引失效，如select userid from table where userid=’ 1234’

4、充分利用前缀索引

必须是最左前缀，不可能同时用到两个范围条件

5、避免使用存储过程、触发器、EVENTS等

让数据库做最擅长的事，降低业务耦合度，为sacle out、shading留点余地，避开BUG 6、避免使用大表的join

MySQL最擅长的是单表的主键/二级索引查询

Join消耗较多的内存，产生临时表

7、避免在数据库中进行数学运算

容易将业务逻辑和DB耦合在一起

MySQL不擅长数学运算和逻辑判断

无法使用索引

8、拒绝大SQL，拆分成小SQL

充分利用多核CPU

9、使用in代替or，in的值不超过1000个

10、禁止使用order by rand()

因为ORDER BY rand()会将数据从磁盘中读取，进行排序，会消耗大量的IO和CPU，可以在程序中获取一个rand值，然后通过在从数据库中获取对应的值

11、使用union all而不是union

12、程序应有捕获SQL异常的处理机制

13、禁止单条SQL语句同时更新多个表

14、不使用select * from 消耗cpu和IO、消耗网络带宽，无法使用覆盖索引，减少表结构变更带来的影响

--------------------------------------------------------------------

7 行为规范

1、批量导入、导出数据必须提前通知DBA协助观察；

2、批量更新数据，如update、delete操作，需要DBA进行审查，并在执行过程中观察服务负载等各种状况；

3、禁止在主库上执行后台管理和统计类的功能查询；

4、禁止有super权限的应用程序账号存在；

5、产品出现非数据库导致的故障时及时通知DBA协助排查；

6、促销活动或上线新功能必须提前通知DBA进行流量评估；

7、数据库数据丢失，及时联系DBA进行恢复；

8、对单表的多次alter操作必须合并为一次操作，相同类型的写操作合并为一条语句；

9、不在MySQL数据库中存放业务逻辑；

10、重大项目的数据库方案选型和设计必须提前通知DBA参与；

11、对特别重要的库表，提前与DBA沟通确定维护和备份优先级；

12、不在业务高峰期批量更新、查询数据库；

13、提交线上建表需求，必须详细注明所有相关SQL。

转载

https://www.360docs.net/doc/633895154.html,/2015/06/19/mysql%E6%95%B0%E6%8D%AE%E5%BA%93%E8%AE%BE%E8%AE%A 1sql%E8%A7%84%E8%8C%83/

MySQL数据库开发规范1.3

平安金融科技数据库（MySQL）开发规范作者: 简朝阳 Last Updated: 25/02/14 19:30:18 历史修订记录：版本修订人修订时间修订内容 1.0 1.1 李海军2013-03-11 增加部分说明及修改 1.2 李海军2013-07-29 增加连接池使用说明和memory引擎的控制 1.3 李海军2014-02-25 增加了char类型，修改了timestamp的使用场合。说明 ?本规范包含平安金融科技使用MySQL 数据库时所需要遵循的所有对象设计（数据库，表，字段），所需要遵循的命名，对象设计，SQL 编写等的规范约定。 ?所有内容都为必须严格执行的项目，执行过程中有任何疑问，请联系DBA Team 取得帮助。概述 ?禁止明文传播数据库帐号和密码。 ?禁止开发工程师通过应用帐号登录生产数据库。 ?禁止应用在服务器安装MySQL客户端（可以安装开发包）。 ?禁止开发人员在SQL中添加Hint，Hint只能由DBA审核后添加。 ?禁止使用悲观锁定，即读锁select … for update。 ?禁止在开发代码中使用DDL语句，比如truncate，alter table … 等。 ?禁止DML语句的where条件中包含恒真条件（如：1=1）。

1. 命名规范总则 ?数据库对象名仅可包含小写英文字母、数字、下划线（_）三类字符，并以英文字母开头。 ?数据库对象命名禁止使用MySQL保留字。 ?多个单词之间用下划线（_）分隔。 ?对象名称长度若超过限制，则使用简写/缩写命名。 1.1. 数据库命名 ?数据库以"db_"前缀+ "站点名_"前缀及其所服务的应用名称命名。 1.2. 表命名 ?所属同一模块的表必须以模块名作为前缀命名。 ?历史数据表在原表基础上增加"_his"后缀命名。 1.3. 字段命名 ?布尔意义的字段以"_flag"作为后缀，前接动词。如：表示逻辑删除意义的字段可命名为delete_flag。 ?各表间相同意义的字段（如：作为连接关系的引用字段）使用相同的字段名。 1.4. 索引命名 ?唯一索引以uk_tablename_columnnames 方式命名 ?普通索引以idx_tablename_columnnames 方式命名 ?组合索引以idx_tablename_column1_column2... 方式命名示例 ?站点名：maymay ?模块名：order ； ?数据表：item； ?字段组成：order_item_id,add_time,raw_update_time,c1,c2,c3,c4,c5 ?标准数据库名：db_maymay_order； ?标准数据表名：order_item； ?历史数据表名：order_item_his；

规范化-数据库设计原则

规范化－数据库设计原则关系数据库设计的核心问题是关系模型的设计。本文将结合具体的实例，介绍数据库设计规范化的流程。摘要关系型数据库是当前广泛使用的数据库类型，关系数据库设计是对数据进行组织化和结构化的过程，核心问题是关系模型的设计。对于数据库规模较小的情况，我们可以比较轻松的处理数据库中的表结构。然而，随着项目规模的不断增长，相应的数据库也变得更加复杂，关系模型表结构更为庞杂，这时我们往往会发现我们写出来的SQL语句的是很笨拙并且效率低下的。更糟糕的是，由于表结构定义的不合理，会导致在更新数据时造成数据的不完整。因此，就有必要学习和掌握数据库的规范化流程，以指导我们更好的设计数据库的表结构，减少冗余的数据，借此可以提高数据库的存储效率，数据完整性和可扩展性。本文将结合具体的实例，介绍数据库规范化的流程。序言本文的目的就是通过详细的实例来阐述规范化的数据库设计原则。在DB2中，简洁、结构明晰的表结构对数据库的设计是相当重要的。规范化的表结构设计，在以后的数据维护中，不会发生插入（insert）、删除（delete）和更新（update）时的异常。反之，数据库表结构设计不合理，不仅会给数据库的使用和维护带来各种各样的问题，而且可能存储了大量不需要的冗余信息，浪费系统资源。要设计规范化的数据库，就要求我们根据数据库设计范式――也就是数据库设计的规范原则来做。但是一些相关材料上提到的范式设计，往往是给出一大堆的公式，这给设计者的理解和运用造成了一定的困难。因此，本文将结合具体形象的例子，尽可能通俗化地描述三个范式，以及如何在实际工程中加以优化使用。规范化在设计和操作维护数据库时，关键的步骤就是要确保数据正确地分布到数据库的表中。使用正确的数据结构，不仅便于对数据库进行相应的存取操作，而且可以极大地简化使用程序的其他内容（查询、窗体、报表、代码等）。正确进行表设计的正式名称就是"数据库规范化"。后面我们将通过实例来说明具体的规范化的工程。关于什么是范式的定义，请参考附录文章1. 数据冗余数据应该尽可能少地冗余，这意味着重复数据应该减少到最少。比如说，一个部门雇员的电话不应该被存储在不同的表中，因为这里的电话号码是雇员的一个属性。如果存在过多的冗余数据，这就意味着要占用了更多的物理空间，同时也对数据的维护和一致性检查带来了问题，当这个员工的电话号码变化时，冗余数据会导致对多个表的更新动作，如果有一个表不幸被忽略了，那么就可能导致数据的不一致性。规范化实例为了说明方便，我们在本文中将使用一个SAMPLE数据表，来一步一步分析规范化的过程。首先，我们先来生成一个的最初始的表。 CREATE TABLE "SAMPLE" ( "PRJNUM" INTEGER NOT NULL, "PRJNAME" VARCHAR(200), "EMYNUM" INTEGER NOT NULL, "EMYNAME" VARCHAR(200), "SALCATEGORY" CHAR(1), "SALPACKAGE" INTEGER)

数据库设计案例-酒店管理系统精品

【关键字】方案、情况、方法、实效、空间、文件、模式、运行、认识、问题、系统、有效、充分、公开、持续、统一、发展、建立、制定、发现、了解、措施、特点、位置、安全、稳定、准则、根本、基础、需要、项目、职能、需求、方式、作用、标准、规模、结构、水平、速度、关系、设置、分析、简化、吸引、逐步、形成、严格、管理、维护、服务、发挥、解决、优化、调整、分工、保障、实现、提高、落实、系统性酒店管理系统一、背景说明目前大多数酒店提供的服务多种多样，规模大小也各不相同，但稍具规模的酒店必含下面三类服务：饮食、住宿和娱乐。由于我们对酒店行业没有具体的接触和实质性的了解。此次数据库设计只能在一些收集到的基本材料与个人直观认识的基础上，简单模仿中等规模的酒店设计管理系统，并将其抽象成一个由三部门组成、实现三大服务的系统。二、部门的划分 1．饮食部门它是酒店基本部门之一。它提供服务的特点是实时性强、持续时间短，强调效率。例如，顾客人数、顾客所用的菜及其它饮料等种类繁多，数量不等；后勤各种活动如采购等频繁发生。通过分析可发现，用人工完成此类操作比计算机更具实效与时效，且此类信息也没有长时间保留的必要，因此这些信息没有必要采用数据库管理。对于饮食部门，需要较长时间保留的信息主要是财务信息，一方面便于期末汇总，另一方面便于向上级报告。在规模较大的酒店餐饮服务部分，餐厅可分成几个等级或几个小部门，然后各自形成小系统，本系统为了简单起见，把饮食部门作为一个子系统，不再细分。 2．住宿管理部门它也是酒店基本部门之一。住宿管理部门的主要职责有：A.给个房间布置各种设备、分类、编号、制定收费标准、分配服务人员。B.登记旅客信息，确认其身份，登记其入住、退房时间。C.统计各类房间的客满程度。D.对本部门的财务流动进行登记处理。以上信息处理可以通过计算机完成，其他不便于计算机操作的在此没有列出。 3．娱乐管理部门娱乐是酒店非主流服务，它的存在除了赢利，更多的是为了吸引顾客食宿。娱乐部门的特点与饮食部门很相似，不便于使用计算机进行操作。可以用计算机完成并且有必要用计算机完成的有：A.制定收费标准，分配负责人.B.收入支出财务处理：编号、财务来源去处的摘要、数量、单价、数额、

MYSQL开发规范

MySQL DB规范

目录简介 (3) 目的 (3) 适用范围 (3) 数据库设计 (3) 引擎及版本选择 (3) 基础规范 (3) 命名规范 (5) 库表设计规范 (5) 字段设计 (6) 常用数据类型： (6) 数据类型使用建议： (6) 索引规范 (8) 索引准则 (8) 索引禁忌 (8) 不使用外键 (9) SQL设计 (10)

简介介绍在使用mysql中各种注意事项和优化细节目的供开发人员参考，合理利用MySQL特性，开发出更高效的代码减少后端数据库压力，让整个系统高效稳定运行适用范围业务数据库使用的是MySQL的数据库。数据库设计实现目标：业务功能实现、数据的扩展性、普遍性适用性业务中80%+的性能优化是来自架构设计的优化引擎及版本选择根据业务特性选择合适的存储引擎，默认选择InnoDB存储引擎，原因如下（MyISAM与InnoDB比较）：基础规范所有库表默认使用INNODB存储引擎,MyISAM适用场景非常少

●库表字符集使用UTF8，原因如下：使用utf8字符集，如果是汉字，占3个字节，但ASCII码字符还是1个字节；统一不会有转换产生乱码风险；其他地区的用户（美国、印度、台湾）无需安装简体中文支持，就能正常看您的文字，并且不会出现乱码。 UTF-8最大的一个特点，就是它是一种变长的编码方式。它可以使用1~4个字节表示一个符号，根据不同的符号而变化字节长度。 UTF-8的编码规则很简单，只有二条： 1）对于单字节的符号，字节的第一位设为0，后面7位为这个符号的unicode码。因此对于英语字母，UTF-8编码和ASCII码是相同的。 2）对于n字节的符号（n>1），第一个字节的前n位都设为1，第n+1位设为0，后面字节的前两位一律设为10。剩下的没有提及的二进制位，全部为这个符号的unicode码。 ●所有表和字段都需要添加注释，以方便其它开发及dba了解 ●单表数据量纯int型建议控制在1000w以内，含char型的建议500w以内，行平均长度控制在16KB以内，单表20GB以内 ●不在数据库中存储图片、文件等大数据.原因如下： 1、对数据库的读写速度永远赶不上文件系统的处理速度 2、数据库备份会变的很臃肿，备份很耗时间 3、对文件的访问需要通过你的应用和数据库 ●临时短命数据尽量不要存到数据库中，建议存放于前端的memcache、redis等nosql中,减少后端数据库压力 ●禁止在线上做压力测试 ●禁止从测试、开发环境直接连接线上数据库 ●用数据库来持久化存储以及保证事务一致性，不是运算器，在应用层实现计算 ●读写分离，主库只写和少量实时读取请求，使用从库来查询。 ●采用队列方式合并多次写请求，持续写入避免瞬间压力 ●超长text/blob进行垂直拆分，并先行压缩 ●冷热数据进行水平拆分（如6个月前后数据），LRU原则 ●快速更新频繁和大数据表禁止直接运行count(*)统计 ●压力分散，在线表和归档表（日志表）分开存储；不重要的非实时查询日志不要存数据库，以文件方式在应用端统计分析。 ●禁止明文存储机密数据，需至少两次加密（部分数据可逆运算）

数据库的设计范式规范化

数据库的设计范式是数据库设计所需要满足的规范，满足这些规范的数据库是简洁的、结构明晰的，同时，不会发生插入（insert）、删除（delete）和更新（update）操作异常。反之则是乱七八糟，不仅给数据库的编程人员制造麻烦，而且面目可憎，可能存储了大量不需要的冗余信息。范式说明 1.1 第一范式（1NF）无重复的列所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。简而言之，第一范式就是无重复的列。说明：在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。例如，如下的数据库表是符合第一范式的：而这样的数据库表是不符合第一范式的：

数据库表中的字段都是单一属性的，不可再分。这个单一属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。很显然，在当前的任何关系数据库管理系统（DBMS）中，傻瓜也不可能做出不符合第一范式的数据库，因为这些DBMS不允许你把数据库表的一列再分成二列或多列。因此，你想在现有的DBMS中设计出不符合第一范式的数据库都是不可能的。 1.2 第二范式（2NF）属性完全依赖于主键 [ 消除部分子函数依赖 ] 如果关系模式R为第一范式，并且R中每一个非主属性完全函数依赖于R 的某个候选键，则称为第二范式模式。第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。这个惟一属性列被称为主关键字或主键、主码。例如员工信息表中加上了员工编号（emp_id）列，因为每个员工的员工编号是惟一的，因此每个员工可以被惟一区分。简而言之，第二范式（2NF）就是非主属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性（设有函数依赖 W→A，若存在XW，有X→A成立，那么称W→A是局部依赖，否则就称W→A 是完全函数依赖）。如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。假定选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分)，关键字为组合关键字(学号, 课程名称)，因为存在如下决定关系：

学生数据库设计实例

学生成绩管理系统目录一：需求分析二：系统功能描述三：E-R图四：数据库逻辑结构设计五：数据库物理设计六：代码设计七：SQL代码八：界面截图一：需求分析：随着学校的规模不断扩大，学生数量急剧增加，有关学生的各种信息量也成倍增长，对学生成绩信息的管理难度随之增大。面队如此庞大的信息量，这就需要学生成绩管理信息系统来提高学生管理工作的效率。通过这样的系统，做到信

息的规范管理、科学统计以及快速的查询和修改，从而减少管理方面的工作量。总体任务是要实现学生成绩信息关系的系统化、规范化和自动化。根据总体任务的要求进行需求分析得出，学生成绩管理信息系统需要完成的功能主要如下：学生基本信息的输入，其中包括学生学号、姓名、性别、所属学院，所属系别，所属班级、出生年月、籍贯、宿舍、联系方式等。学校基本课程信息的输入，包括课程编号、课程名称、课程属性、课程描述以及完成该课程所得的学分。教师基本信息的输入，其中包括教师编号，教师姓名，教师职称，所教课程，所教班级等情况学生信息，教师信息，课程信息，学生考试成绩的插入，删除，修改、查询和统计。识别每个用户的身份和密码，从而保证信息的安全性，防止信息的外泄和盗用。还有，涉及到信息的增，删，改的，主要都是面向教务管理员，教师只能录入成绩，查询成绩，修改成绩，和查询个人信息，而学生只能登录查看自己的信息，查询成绩等。二：系统功能描述教务处（管理员）教师学生

院

三：E-R图（概念结构建立）1）学生查询系统的分E-R图

2）教师查询更新系统的分E-R图 3）管理员分E－R图

MySQL数据库教案

任务引入[5分钟] 课程介绍[20分钟] 认识数据库提问：按自己的理解，说说数据库是什么？展示各类网站商城网站页面是大家在熟悉不过的了，商城网站上的商品琳琅满目，让人流连忘返。但是在大家欣赏自己喜爱的商品之余，是否想过商城网站上的文字信息、图片信息等存放在哪里呢？当大家在商城网站上进行注册用户时，自己的信息又存在哪里呢？当客户在商城网站上留言的时候，留言信息又放在哪里了呢？这就是本门课程——《WEB数据库应用》要解决的问题。主要让学生明确以下几个问题： 1．明确课程定位与作用专业基础课，与《程序设计基础》一起，为《网站建设》奠定基础。同时兼顾计算机二级考试相关内容。通过任务引领型和项目活动形式，掌握简单的数据库设计、数据管理和维护方法，能进行web服务器的设置，具备使用web数据库与高级程序设计语言或动态网页结合完成简单程序开发的基本职业能力。 2．明确课程内容内容的确定遵循两个原则：一是满足后续课程的基本需求，二是为学生进一步的学习提供必要的准备。通过对学生就业岗位和用人单位对本专业毕业生设置的招聘岗位等分析，课程内容应基本包括数据库系统概述、关系理论、关系数据库查询语言SQL、数据库设计与关系规范化理论、MySQL 数据中管理系统与高级程序设计语言或动态网页技术结合的简单应用。 3．强调学习方法（1）与以往《计算机基础》、《办公软件应用》在学习方法上不同，知识与操作的连续性更强，在学习上要坚持一贯，持之以恒。提问展示展示课程标准、课程体系图与教材配合

新知识[45分钟] （2）课程难度加大，要求大家认真听、认真做，尤其要认真思考。逐渐养成举一反三的习惯、锻炼独立进行逻辑思维的能力。（3）要学会自学。（4）要善于和老师沟通。（5）要学会团队协作。 4．明确考核方式（1）日常评价由三个部分组成：出勒（20%）、学习积极主动性（40%）、任务完成情况（40%）（2）终结评价平时：20% 期中：20% 期末：40% 一、数据库基本概念请学生回忆从小学——初中——高中——大学，每个期末处理成绩的过程，大部分都有帮助老师统计分数的经历。提问： 1．你用过哪些方式协助老师统计分数？ 2．在这个过程中你发现了什么变化？为什么产生这样的变化？经过充分的讨论发言之后，让学生总结为什么产生数据库技术，并简单说明其发展阶段：第一代：网状、层次数据库系统第二代：关系型数据库系统第三代：以面向对象模型为主要特征的数据库系统二、数据库基本概念 1．数据数据是存储在数据库中的基本对象，包括数字、文字、图形、图像和声音等。 2．数据库数据库简单地说就是存放数据的仓库。这些数据是按照一定的格式存放在计算的存储设备上。

数据库设计的案例分析

图书销售建立某中小型书店图书销售管理信息系统的数据库。 1. 基本需求分析 1）组织结构对组织结构的分析有助于分析业务范围与业务流程。书店的组织结构如图三所示。图三书店组织结构简图其中，书库是保存图书的地方；购书/服务部负责采购计划、读者服务、图书预订等业务；售书部负责图书的销售。财务部负责资金管理；人事部负责员工管理与业务考核。 2）业务分析对于信息处理系统来说，划分系统边界很重要，即哪些功能由计算机来完成，哪些工作在计算机外完成。这些要通过业务分析确定。同时，业务流程中涉及的相关数据也通过业务分析得到归类和明确。在业务分析的基础上，确定数据流图和数据字典。本系统主要包含以下业务内容。 ①进书业务。事先采购员根据订书单采购图书。然后将图书入库，同时登记相应的图书入库数据。本项业务涉及的数据单据和表格有：进书单（包括进书单编号、日期、金额、经手人等）和进书单细目（一个进书单可能有若干种图书。进书单的细目数据包括每种图书的信息、定价、进价或折扣，数量），以及书库账本（图书信息、库存数量、价格等）。 ②售书业务。售书员根据读者所购图书填写售书单（如图四所示）。同时，修改库存信息。

本项业务涉及和产生的数据表格有：售书单（包括售书单编号、售书日期、金额、员工）、售书细目（一个售书单可能有若干种图书。售书细目包括该次售书的书籍编号、售出数量、折扣、售出价格等），以及书库账本。图四售书单样式 ③图书查询服务业务。根据读者要求，提供本书店特定的图书及库存信息。本项业务涉及的主要数据是书库账本。 ④综合管理业务。包括进书信息、销售信息、库存信息的查询、汇总和报表输出。本项业务涉及所有的进书数据、销售数据和库存数据等。 3）处理的数据上面的分析将本系统的业务归纳为4项。在业务分析的基础上，应该画出系统的数据流图。整个系统的分层数据流图将揭示一个系统内全部的数据项、数据结构、数据存储以及对数据的加工处理功能。在此基础上就可以建立系统的数据字典。本书不讨论数据流图和完整的数据字典规范等内容，仅对最后建立数据库所需要的数据进行分析说明。在上述4项业务中涉及到的业务数据包括：进书数据、库存数据、销售数据。在这些数据中又涉及到图书数据、员工数据等，而图书数据与出版社有关，员工与部门有关。因此，将所有数据进行归类分析，书店销售管理信息系统要处理的数据应该包括：

SQL_Server数据库设计的案例分析报告

数据库设计的案例分析一、教学管理 1. 基本需求某学校设计学生教学管理系统。学生实体包括学号、、性别、生日、民族、籍贯、简历、登记照，每名学生选择一个主修专业，专业包括专业编号和名称，一个专业属于一个学院，一个学院可以有若干个专业。学院信息要存储学院号、学院名、院长。教学管理还要管理课程表和学生成绩。课程表包括课程号、课程名、学分，每门课程由一个学院开设。学生选修的每门课程获得一个成绩。设计该教学管理的ER模型，然后转化为关系模型。若上面的管理系统还要管理教师教学安排，教师包括编号、、年龄、职称，一个教师只能属于一个学院，一名教师可以上若干门课程，一门课程可以有多名老师来上，每个教师所上的每门课都有一个课堂号和课时数。试修改上题的ER 模型，将教师教学信息管理增加进去。

2. 参考设计：图一教学管理ER图由ER模型转换的关系模型是：学生（学号，，性别，生日，民族，籍贯，专业号，简历，登记照）专业（专业号，专业，专业类别，学院号）学院（学院号，学院，院长）课程（课程号，课程名，学分，学院号）成绩（学号，课程号，成绩）（题目分析：本题中有学生、专业、学院、课程四个实体。一个学生只有一个主修专业，学生与专业有多对一的联系；一个专业只由一个学院开设，一门课程只由一个学院开设，学院与专业、学院与课程都是一对多的联系；学生与课程有多对多的联系。在转换为关系模型时，一对多的联系都在相应的多方实体的关系中增加一个外键。）增加教师，ER图如下。

图二有教师实体的教学管理ER图 3. 物理设计基于Access的数据库结构设计如下。指定数据库文件的名称，并为设计好的关系模型设计表结构。数据库文件保存在“E:\教学管理\”文件夹中，数据库文件名：教学管理.MDB。表包括：学院、专业、学生、课程、成绩单。对应表结构如表1-2至表1-6所示。表1-1 学院字段名类型宽度小数主键/索引参照表约束Null 值学院号文本型 2 ↑（主）学院文本型16 院长文本型8 √ 表1-2 专业字段名类型宽度小数主键/索引参照表约束Null 值专业号文本型 4 ↑（主）专业文本型16 专业类别文本型8 ↑ 学院号文本型 2 学院表1-3 学生字段名类型宽度小数主键/索参照表约束Null

全国计算机等级考试二级MySQL数据库程序设计

全国计算机等级考试二级MySQL数据库程序设计考试大纲(2013年版) 基本要求: 1. 初步掌握数据库技术的基本概念、原理、方法和技术; 2. 熟练掌握MySQL 的安装及配置技能; 3. 熟练使用MySQL 平台下的SQL 语言实现数据库的交互操作; 4. 熟悉一种MySQL 平台下的一个应用系统开发的主语言(C/ Perl/ PHP),并初步具备利用该语言进行简单应用系统的开发能力; 5. 掌握MySQL 平台下的数据库管理与维护技术。考试内容: 一、基本概念与方法 1. DBS 三级(模式、外模式、内模式)结构; 2. DBS 的运行与应用结构(C/ S、B/ S); 3. 关系规范化的基本方法。二、数据库设计 1. 概念设计; 2. 逻辑设计; 3. 物理设计。三、SQL 交互操作利用MySQL 进行数据库表、数据及索引的创建、使用和维护。四、MySQL 的日常管理 1. MySQL 安装与配置技能; 2. MySQL 的使用及数据访问的安全控制机制; 3. MySQL 数据库的备份和恢复方法; 4. 性能调优技术。五、MySQL 的应用编程 1. 触发器、事件及存储过程的使用方法; 2. MySQL 平台下的C 语言(或Perl/ PHP)的应用程序编制。考试方式: 上机考试120 分钟,满分100 分。上机考试题型及分值: 单项选择题40 分(含公共基础知识部分10 分)、操作题60 分(包括基本操作题、简单应用题及综合应用题)。

上机考试内容： 1. 考试环境: 数据库管理系统:MySQL 编程语言:C/ Perl/ PHP 2. 在上述环境下完成如下操作: 创建和管理数据库;数据查询;安全管理;数据库备份与恢复;数据导入与导出。 3. 在上述环境下开发C/ S 或B/ S 结构下的一个简单应用系统。

物流管理系统的数据库设计(六个基本步骤)案例分析

物流管理信息系统的数据库设计（案例分析）系统名称：物流管理信息系统（数据库管理系统）一、需求分析需求分析是整个数据库设计过程的基础，要收集数据库所有用户的信息内容和处理要求，并加以规格化和分析。物流管理系统是为制造商和零售商设计的管理系统数据库系统，目的是： 1、实现上游制造商的信息管理。 2、实现下游零售商的信息管理。 3、实现进库与配送的信息管理。从而提高物流效率，降低物流成本并提高企业管理化水平。经过调研分析，得到系统的如下功能需求。（1）数据检索 1、制造商、零售商查询某一产品名称，规格和单位输入：产品编号输出：产品名称，产品规格，产品单位，制造商编号 2、物流中心、制造商查询某一零售商名称，联系人，地址，电话号码，网址输入：零售商编号输出：零售商名称，联系人，地址，电话号码，网址 3、零售商、物流中心查询某一制造商信息表输入：制造商编号

输出：制造商名称，联系人，地址，电话号码，网址 4、物流中心、制造商、零售商查询某一产品的出库信息表输入：仓库编号输出：仓库编号，库名，地址，电话 5、物流中心、零售商查询某一产品的制造商和产品信息表输入：产品编号编号输出：制造商名称,联系人,地址,电话号码,网站,产品名称,产品名称,产品规格,产品单位 6、查询某一产品对应的物流中心编号及产品信息输入：产品编号输出：物流中心编号,货物价格,提取.产品编号,产品.产品名称,产品名称,产品规格,产品单位 7、制造商，零售商查询某一物流中心信息输入：物流中心编号输出：物理中心名称，联系人，地址，电话号码，网址（2）数据插入 ①产品数据插入 ②制造商数据插入 ③零售商数据插入 ④物流中心数据插入（3）数据修改 ①产品数据修改：某产品数据变化时，输入该产品编号以及需修改的属性，

数据库设计规范

文档信息作者：创建日期（yyyy-mm-dd）: 审核者: 审核日期（yyyy-mm-dd）: 最后修订者：最后修订日期（yyyy-mm-dd）: 文档类型：文档修订历史版本号修订日期修订者修订内容1.0.0 2011.9.20 金洋初始化

数据库约定对应于XXXX MYSQL数据库环境的数据库类型定义如下表：1 Development Database 开发环境使用开发环境数据库 2 Quality Assurance Database 质保环境使用质保环境数据库 3 Production Database 生产环境使用生产环境数据库 4 Training Database 培训环境使用培训环境数据库 5 SIT Database 集成测试环境使用集成测试环境数据库数据库字符集选择UTF8字符集 (建库时确定) 1. 数据库元素命名规范长度约定：字段名，表名，视图名称等长度不能超过25个字符1.1. 表命名规范数据类型数据类型（英文）前缀主数据Master Data Table TM 业务事务处理数据Transaction Data Table TT 关系表Relationship Table TR 代码列表Code List Table TC 接口表Interface Table TI 系统管理表System administration Table TS 日志表Log Table TL 历史表History Table TH 中间临时表Temparory table TE 汇总表Aggregation Table TA 归档表Archivie Table TZ

数据库案例分析与设计

数据库案例分析与设计考核题 1203批次前老平台学生，该门课程不用现场笔试考试（网上预约考试时间为虚设），请预约该门课程考试的学生将答案手写A4答题纸上，于规定时间内交到学习中心，哈站交到班主任处。未预约的学生提交的内容作废处理，预约后不按规定时间提交按旷考处理。（答题纸附在第二页，所有答案必须写在答题纸上，标清题号）一．设计报告的题目要求在以下三个题目中选择一个，作为数据库应用系统设计的内容，进行必要的走访和调研完成你的设计报告。 1.人事信息管理系统调研一个中等规模的机构或单位，完成该单位的人事信息管理系统的设计工作。以满足基本的人事管理功能：比如员工的基本信息管理，如编号、姓名、性别、学历、所属部门、毕业院校、健康情况、职称、职务、奖惩等；员工各种信息的修改；对转出、辞退、退休员工信息的删除；按照一定条件，查询、统计符合条件的员工信息；人事的调动任免信息的管理；按条件查询、统计，结果打印输出等。 2.超市会员管理系统调研一个具有会员管理功能的商场或超市等，完成该单位的基本会员信息管理系统的设计。比如加入会员的基本信息，包括：会员的基本条件、优惠政策、优惠时间等。会员的基本信息，包括姓名、性别、年龄、工作单位、联系方式等。会员购物信息：购买物品编号、物品名称、所属种类，数量，价格等。会员返利信息,包括会员积分的情况，享受优惠的等级等。对货物流量及消费人群进行统计输出等。 3.客房管理系统调研一个中等规模的宾馆，完成该宾馆的客房管理信息系统的设计。实现客房管理的基本功能，包括客房的类别、当前的状态、负责人等；客房信息的查询和修改，包括按房间号查询住宿情况、按客户信息查询房间状态等。以及退房、订房、换房等信息的修改等。二．设计报告的内容要求给出数据库系统的6个设计阶段的主要工作内容，其中(1)-(4)必做，(5)-(6)选做： (1)需求分析：收集并分析用户的基本要求，简要概述系统的设计目标；详细描述用户对数据库的要求，明确用户需求；给出主要的用户活动图、数据流图和数据字典等。 (2)概念结构设计：对具体应用建模，给出数据间的关系模型；利用需求分析得到的数据内容等给出主要的实体关系图(E-R图)，并详细描述实体和关系的属性等。 (3)逻辑结构设计：得到具体的关系模式集，并适当优化；利用得到的E-R图，转换为具体的关系结构，并标明相互关联和各自的主键等具体内容；采用水平分解或垂直分解等方法，进行适当的优化。 (4)物理结构设计：选用一种DBMS，利用SQL语句给出数据库内模式的设计等；根据得到的关系结构和选用的DBMS，进行关系构建具体的SQL语句，确定文件的存储方式、表的索引方式等。 (5)数据库实施：前端应用程序的设计等。 (6)数据库运行和维护：数据库的测试及运行过程。

数据库设计格式规范

1) 标准化和规范化数据的标准化有助于消除数据库中的数据冗余。标准化有好几种形式，但Third Normal Form（3NF）通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。简单来说，遵守3NF 标准的数据库的表设计原则是： “One Fact in One Place”即某个表只包括其本身基本的属性，当不是它们本身所具有的属性时需进行分解。表之间的关系通过外键相连接。它具有以下特点：有一组表专门存放通过键连接起来的关联数据。举例：某个存放客户及其有关定单的3NF 数据库就可能有两个表：Customer和Order。Order表不包含定单关联客户的任何信息，但表内会存放一个键值，该键指向Customer表里包含该客户信息的那一行。事实上，为了效率的缘故，对表不进行标准化有时也是必要的。 2) 数据驱动采用数据驱动而非硬编码的方式，许多策略变更和维护都会方便得多，大大增强系统的灵活性和扩展性。举例，假如用户界面要访问外部数据源（文件、XML 文档、其他数据库等），不妨把相应的连接和路径信息存储在用户界面支持表里。还有，如果用户界面执行工作流之类的任务（发送邮件、打印信笺、修改记录状态等），那么产生工作流的数据也可以存放在数据库里。角色权限管理也可以通过数据驱动来完成。事实上，如果过程是数据驱动的，你就可以把相当大的责任推给用户，由用户来维护自己的工作流过程。 3) 考虑各种变化在设计数据库的时候考虑到哪些数据字段将来可能会发生变更。举例，姓氏就是如此（注意是西方人的姓氏，比如女性结婚后从夫姓等）。所以，在建立系统存储客户信息时，在单独的一个数据表里存储姓氏字段，而且还附加起始日和终止日等字段，这样就可以跟踪这一数据条目的变化。 2.数据库涉及字符规范采用26个英文字母(区分大小写)和0-9这十个自然数,加上下划线'_'组成,共63个字符.不能出现其他字符(注释除外). 注意事项: 1) 以上MYSQL数据库命名都不得超过30个字符的系统限制.变量名的长度限制为 29(不包括标识字符@). 2) 数据对象、变量的命名都采用英文字符,禁止使用中文命名.绝对不要在对象名的字符之间留空格. 3) 小心保留词,要保证你的字段名没有和保留词、数据库系统或者常用访问方法冲突 5) 保持字段名和类型的一致性,在命名字段并为其指定数据类型的时候一定要保证一致性.假如数据类型在一个表里是整数,那在另一个表里可就别变成字符型了.

数据库设计规范化的五个要求

数据库设计规范化的五个要求通常情况下，可以从两个方面来判断数据库是否设计的比较规范。一是看看是否拥有大量的窄表，二是宽表的数量是否足够的少。若符合这两个条件，则可以说明这个数据库的规范化水平还是比较高的。当然这是两个泛泛而谈的指标。为了达到数据库设计规范化的要求，一般来说，需要符合以下五个要求。要求一：表中应该避免可为空的列。虽然表中允许空列，但是，空字段是一种比较特殊的数据类型。数据库在处理的时候，需要进行特殊的处理。如此的话，就会增加数据库处理记录的复杂性。当表中有比较多的空字段时，在同等条件下，数据库处理的性能会降低许多。所以，虽然在数据库表设计的时候，允许表中具有空字段，但是，我们应该尽量避免。若确实需要的话，我们可以通过一些折中的方式，来处理这些空字段，让其对数据库性能的影响降低到最少。一是通过设置默认值的形式，来避免空字段的产生。如在一个人事管理系统中，有时候身份证号码字段可能允许为空。因为不是每个人都可以记住自己的身份证号码。而在员工报到的时候，可能身份证没有带在身边。所以，身份证号码字段往往不能及时提供。为此，身份证号码字段可以允许为空，以满足这些特殊情况的需要。但是，在数据库设计的时候，则可以做一些处理。如当用户没有输入内容的时候，则把这个字段的默认值设置为0或者为N/A。以避免空字段的产生。二是若一张表中，允许为空的列比较多，接近表全部列数的三分之一。而且，这些列在大部分情况下，都是可有可无的。若数据库管理员遇到这种情况，笔者建议另外建立一张副表，以保存这些列。然后通过关键字把主表跟这张副表关联起来。将数据存储在两个独立的表中使得主表的设计更为简单，同时也能够满足存储空值信息的需要。要求二：表不应该有重复的值或者列。如现在有一个进销存管理系统，这个系统中有一张产品基本信息表中。这个产品开发有时候可以是一个人完成，而有时候又需要多个人合作才能够完成。所以，在产品基本信息表产品开发者这个字段中，有时候可能需要填入多个开发者的名字。如进销存管理中，还需要对客户的联系人进行管理。有时候，企业可能只知道客户一个采购员的姓名。但是在必要的情况下，企业需要对客户的采购代表、仓库人员、财务人员共同进行管理。因为在订单上，可能需要填入采购代表的名字;可是在出货单上，则需要填入仓库管理人员的名字等等。为了解决这个问题，有多种实现方式。但是，若设计不合理的话在，则会导致重复的值或者列。如我们也可以这么设计，把客户信息、联系人都放入同一张表中。为了解决多个联系人的问题，可以设置第一联系人、第一联系人电话、第二联系人、第二联系人电话等等。若还有第三联系人、第四联系人等等，则往往还需要加入更多的字段。可是这么设计的话，会产生一系列的问题。如客户的采购员流动性比较大，在一年内换了六个采购员。此时，在系统中该如何管理呢?难道就建立六个联系人字段?这不但会导致空字段的增加，还需要频繁的更改数据库表结构。明显，这么做是不合理的。也有人说，可以

MySQL数据库开发规范精编WORD版

M y S Q L数据库开发规范精编W O R D版 IBM system office room 【A0816H-A0912AAAHH-GX8Q8-GNTHHJ8】

平安金融科技数据库（MySQL）开发规范作者: 简朝阳 Last Updated: 25/02/14 19:30:18 历史修订记录：修订时间修订内容版本修订人 1.0 1.1李海军2013-03-11增加部分说明及修改 1.2李海军2013-07-29增加连接池使用说明和memory引擎的控制增加了char类型，修改了timestamp的使用 1.3李海军2014-02-25 场合。说明本规范包含平安金融科技使用 MySQL 数据库时所需要遵循的所有对象设计（数据库，表，字段），所需要遵循的命名，对象设计，SQL 编写等的规范约定。所有内容都为必须严格执行的项目，执行过程中有任何疑问，请联系 DBA Team 取得帮助。

概述禁止明文传播数据库帐号和密码。禁止开发工程师通过应用帐号登录生产数据库。禁止应用在服务器安装MySQL客户端（可以安装开发包）。禁止开发人员在SQL中添加 Hint，Hint只能由DBA审核后添加。禁止使用悲观锁定，即读锁select … for update。禁止在开发代码中使用DDL语句，比如 truncate，alter table … 等。禁止DML语句的where条件中包含恒真条件（如：1=1）。 1. 命名规范总则数据库对象名仅可包含小写英文字母、数字、下划线（_）三类字符，并以英文字母开头。数据库对象命名禁止使用MySQL保留字。多个单词之间用下划线（_）分隔。对象名称长度若超过限制，则使用简写/缩写命名。 1.1. 数据库命名数据库以"db_"前缀 + "站点名_"前缀及其所服务的应用名称命名。

数据库设计文档

XXX系统 (1) 数据库设计说明书 (1) 1引言 (2) 1.1编写目的 (2) 1.2术语表 (2) 1.3参考资料 (3) 2数据库环境说明 (3) 3数据库的命名规则 (4) 4逻辑设计 (4) 5物理设计 (5) 5.1表汇总 (5) 5.2表[X]：[XXX表] (5) 5.3视图的设计 (7) 5.4存储过程、函数及触发器的设计 (7) 6安全性设计 (7) 6.1防止用户直接操作数据库的方法 (7) 6.2用户帐号密码的加密方法 (8) 6.3角色与权限 (8) 7优化 (8) 8数据库管理与维护说明 (8) 一、引言 1.1 编写目的例如：本文档是xx系统概要设计文档的组成部分，编写数据库设计文档的目的是：明确数据库的表名、字段名等数据信息，用来指导后期的数据库脚本的开发，本文档遵循《xx 数据库设计和开发规范》。本文档的读者对象是需求人员、系统设计人员、开发人员、测试人员。 1.2 术语表

1.3 参考资料列出有关资料的名称、作者、文件编号或版本等。参考资料包括：a．需求说明书、架构设计说明书等； b．本项目的其他已发表的文件；二、需求规约提示：本部分完成此数据库系统业务描述和需求分析 2.1 业务描述提示：本部分完成此数据库系统的业务描述，例如：（1）数据库系统创建的背景（2）数据库系统要解决的问题（3）数据库系统要完成的业务流程及工作内容（4）揭示该数据库的资源需求和设计约束 2.2 需求分析提示：本部分完成此数据库系统的需求分析，例如：（1）分析该业务流程的内在联系（2）业务流程各个节点的依赖关系在数据上的反映（3）揭示创建此数据库系统的目的、目标、已知条件（4）将业务流程节点抽象成数据库对象

MYSQL数据库命名及设计规范

MYSQL数据库命名及设计规范 1.设计原则 1)标准化和规范化数据的标准化有助于消除数据库中的数据冗余。标准化有好几种形式，但Third Normal Form（3NF）通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。简单来说，遵守3NF标准的数据库的表设计原则是：“One Fact in One Place”即某个表只包括其本身基本的属性，当不是它们本身所具有的属性时需进行分解。表之间的关系通过外键相连接。它具有以下特点：有一组表专门存放通过键连接起来的关联数据。举例：某个存放客户及其有关定单的3NF数据库就可能有两个表：Customer和Order。Order表不包含定单关联客户的任何信息，但表内会存放一个键值，该键指向Customer表里包含该客户信息的那一行。事实上，为了效率的缘故，对表不进行标准化有时也是必要的。 2)数据驱动采用数据驱动而非硬编码的方式，许多策略变更和维护都会方便得多，大大增强系统的灵活性和扩展性。举例，假如用户界面要访问外部数据源（文件、XML文档、其他数据库等），不妨把相应的连接和路径信息存储在用户界面支持表里。还有，如果用户界面执行工作流之类的任务（发送邮件、打印信笺、修改记录状态等），那么产生工作流的数据也可以存放在数据库里。角色权限管理也可以通过数据驱动来完成。事实上，如果过程是数据驱动的，你就可以把相当大的责任推给用户，由用户来维护自己的工作流过程。 3)考虑各种变化在设计数据库的时候考虑到哪些数据字段将来可能会发生变更。举例，姓氏就是如此（注意是西方人的姓氏，比如女性结婚后从夫姓等）。所以，在建立系统存储客户信息时，在单独的一个数据表里存储姓氏字段，而且还附加起始日和终止日等字段，这样就可以跟踪这一数据条目的变化。 2.数据库涉及字符规范采用26个英文字母(区分大小写)和0-9这十个自然数,加上下划线'_'组成,共63个字符.不能出现其他字符(注释除外). 注意事项: 1)以上命名都不得超过30个字符的系统限制.变量名的长度限制为29(不包括标识字符@). 2)数据对象、变量的命名都采用英文字符,禁止使用中文命名.绝对不要在对象名的字符之间留空格. 3)小心保留词,要保证你的字段名没有和保留词、数据库系统或者常用访问方法冲突 5)保持字段名和类型的一致性,在命名字段并为其指定数据类型的时候一定要保证一致性.假如数据类型在一个表里是整数,那在另一个表里可就别变成字符