如有错误欢迎大家指出。这段时间在家里,做了点修正。
1、慎重选择表名。
有两种选择:
按照多数开发语言的命名规则。比如(myCustomer)。
按照多数开源思想命名规则。比如(my_customer)。
按照咱们中国人的思想。比如(我的客户)。
第一种有个缺点,很容易忘掉大写的字母。
第二种则比较好,每个WORD间用下划线连接,避免遗忘。
第三种建议不要用,虽然很好记。不觉得解析这个表的时候还需要编码转化吗?我个人理解,大家可以补充。
2.关于编码的设定。
A.GBK/GB2312.(适用于纯中文存储)。
B.UTF8.(适用于中英文混合存储)。
C.LATIN1。(适用于纯英文存储)。
D. 其他的。
3.关于表引擎的选择。
A.MYISAM.(很多人说她的表级锁定会带来好多问题,其实只要设计好对应的表以及写好对应的SQL查询就没有那么大的问题。)
B.INNODB.(如果要用到事务,选择她不会错。至于多数人讲的MASTER/SLAVE结构上用INNODB在MASTER的选择是否正确,就要看你怎么用了。不能一味的疯狂使用INNODB。除非你想要确保非常高可用性,
)
C.CSV.(以前我写过文章,关于这个引擎。个人觉得最主要的是来存储少量数据以及从EXCEL到MYSQL的转换方面会很有用。当然只要涉及到规则数据的导入,她就可以办到。)
D.BLACKHOLE.(觉得最完美的用处在于MASETR/SLAVE上面,并且MASTER是一个临时的专门负责写的机器。不过缺点也很多,会与MYISAM或者INNODB或者其他的引擎有所冲突,这点自己要做个权衡)。
E.MEMORY.(应该说是MYISAM的兄弟了。不过在读内存总比读磁盘的速度要快。不过要注意,它不支持动态数据类型)。
F.FEDERATED.(典型的分布式引擎。我以前文章中有介绍。)
G. NDB。(网络版存储引擎。因为Replication 总是有延迟,所以如果系统容不得任何延迟,就用这个吧。)
H. FOLCON。(6.0后用来代替INNODB的引擎。)
4.关于属性数据类型的选择。
A.INT(一个字节的TINYINT,两个字节的SMALLINT,三个字节的MEDIUMINT,四个字节的INT,8个字节的BIGINT。记住:UNSIGNED不管你定义或者不定义,都不影响内部的存储字节大小)
B.少于10个字符用CHAR是在合适不过了。(不过要记住在MEMORY引擎里面会自动把VARCHAR转化为CHAR)
C.我一般用DECIMAL或者NUMERIC来代替FLOAT或者DOUBLE。因为老板要求精确的数字。如果不要求精确的,那就用FLOAT吧。速度快,占空间小。(DECIMA、FLOAT(P)是动态存储。比如
ECIMAL(10,2)占用5个字节。FLOAT占4个字节,)
D.BLOB,TEXT,VARCHAR(一般存放文章内容,特别是新闻网站。需要的字节数是所存储的字符长度+1。记住BLOB和VARCHAR是TEXT和CHAR的BINARY类型)
E.ENUM(在一定范围内绝佳的代替VARCHAR和CHAR的工具,因为她只占一到两个字节。)
F.时间和日期类型(占3个字节的DATE,8个字节的DATETIME,4个字节的TIMESTAMP,3个字节的TIME,1个字节的YEAR。)。如果要存储比如‘1983’这样的年份,用YEAR明显比VARCHAR或者CHAR要节省空间。因为后者要占5个字节。
G.BOOLEAN(用来存储YES或者NO之类的值,占用一个字节。)
H.关于自增字段。目前我们的项目中涉及到好多ORDER BY RAND()操作。此类语句在数据库并发大的时候会造成CPU严重阻塞,持续产生数据库死锁!解决此类问题最好的办法就是利用自增字段,用程序随即生成数字序列,或者在数据库端随即生成数字序列。
I.关于ZEROFILL。非常好用的前置填补0的存储,而不是用用对应个数的空串来代替。在需要前置补零的操作中INT ZEROFILL可以用来代替CHAR或者VARCHR。
5.关于默认值。
A.在5.0之后,只要设定字段为NOT NULL,系统自动给出默认值。对应CHAR->’’,INT->0,BOOLEAN->0等等。
B.在5.0之前的版本,需要手动指定默认值,否则会出现一定的异常。到时候查都不好查了。
6.关于多数据库建立。
A.应该把对应的业务放在各自不同的数据库里,而不是所有业务放到一个库里面。
B.数据库的命名和表命名一样。
7.关于索引。
A.设计表初期尽量考虑到应该建立的索引。所有建立的索引一定要测试一下,看是否有必要,否则会翻倍的减少写数据的性能。
B.对于只有存储0或者1的列,尽量干掉索引,单独分出两个表。一个代替0,另外一个代替1。或者在一个字段里面用EMUM或者CHAR(0)或者CHAR(1)来代替。
PS: 最后一个要值得注意的,就是尽量所有的字段用NOT NULL。虽然MYSQL可以对NULL列进行索引,不过我不建议。
分享到:
相关推荐
本文简要介绍数据库规范化的基本概念和一些需要注意并力求避免的常见问题。 1.理解您的数据 在设计表之前,应明确您打算如何处理数据,还要了解随着时间的推移数据会发生 什么样的变化。您所做的假设将会影响最终的...
消除部分依赖,大 部分情况下,数据库设计都应该达到第二范式。 第 3 规范 一个非关键字段不能依赖于另一个非关键字段。 消除传递依赖, 达到第三范式应该是系统中大部分表的要求, 除非一些特殊作用的表。 更高的...
数据库设计规范 [v1.0] 目 录 第1章 目的 3 第2章 设计规范 3 2.1 规范约定 3 2.2 字段规范 3 第3章 使用规范 3 3.1 综合 3 3.2 查询 5 3.3 增加 5 3.4 删除 5 3.5 修改 5 第4章 其它说明 5 目的 为了优化数据库的...
值得注意的是,在进行数据库物理结构设计时,通常并不知道所有的事务,上述信息可能不完全。所以,以后可能需要修改根据上述信息设计的物理结构,以适应新事务的要求。 1. 确定关系模型的存取方法 确定数据库的...
⽤户登录系统数据库表设计 ⽤户登录系统数据库表设计 最近看了看公司后台⽤户登录系统的设计, ⽐较混乱, 主要还是因为URS和Oauth以及URS第三⽅这三个登录形式各不相同导致的。 下⾯着重介绍⼀下涉及到第三⽅登录中...
5. 理解数据更新操作时应注意数据完整性约束。 6. 了解数据库备份、恢复及导入、导出的概念及方法。 实验要求: 1. 独立完成实验 2. 提交比较规范的实验报告 实验内容: 1.使用企业管理器和查询分析器创建教学管理...
4 数据库逻辑设计 表设计中应注意的问题: 1.对于字符类型的字段,要仔细确认字段的可能长度。在oracle数据库设计中,一 般来说,对于定长的字符数据字段,取字符类型(char),对于不定长的,取变长字符类 型...
这份资源是一份记账本的数据库表结构设计,包含了五个表:User表、Account表、Category表、Transaction表和Budget表。这些表之间存在复杂的关系,通过这些表的设计,可以实现用户注册、账户管理、收支分类、交易记录...
数据库课程设计-高校图书馆管理系统管理系统
数据库设计说明书 版本:V1.0 文 档 编 号 保 密 等 级 作 者 最后修改日期 审 核 人 最后审批日期 批 准 人 最后批准日期 修订记录 日期 版本 修订说明 修订人 目 ...
数据库设计:⽤户登录系统数据库表设计 数据库设计:⽤户登录系统数据库表设计 ⽤户登录系统数据库表设计 ⽤户登录系统数据库表设计 最近看了看公司后台⽤户登录系统的设计, ⽐较混乱, 主要还是因为URS和Oauth以及...
掌握数据库设计的全过程;设计E-R模型,掌握表的创建语句,注意表的约束的应用:主键,外键及check约束;学会使用数据库辅助设计工具软件;掌握查询、增删改等数据操作语句;掌握视图的建立与删除方法并体会其作用;...
一个系统的性能的提高,不单单是试运行或者维护阶段的性能调优的任务,也不单单是开发阶段的事情,而是在整个软件生命周期都需要注意,进行有效工作才能达到的。...该笔记中讨论了在设计数据库时应注意的事项。
XXX数据库设计规范模板 目 次 1 范围 2 引用文件 3 术语、定义和缩略语 3.1 术语 3.2 缩略语 4 总体要求 4.1 数据库设计总体要求 4.2 数据库编程总体要求 5 数据库设计要求 5.1 数据库字符集选择 5.2 数据库表空间...
写出数据库设计中遇到的问题及体会。 注意事项: 每个同学建立各自的数据库,数据库名统一命名为DX,X为各自班级和姓的全 拼。比如,对于01班的黄德才(huang de cai)同学,其数据库名为D01huangdecai; 为便于检查,...
数据库设计从需求分析到ER图设计和逻辑设计,直到单表设计需要注意的问题。
"使用Visio进行数据库设计 " 内容提纲: 1、数据库模型的定义 2、VISIO中数据库模型的分类 3、建立逻辑模型 4、建立物理模型 5、Sql Server导入数据到Visio "VISIO提供了强大的数据库建模功能,利用VISIO可以很方便的...
实验一 数据库设计 一、实验目的 使用规范的数据库设计方法,分析并设计"FLY(飞翔)信息管理系统"的数据库。 二、实验要求 1. 掌握数据库设计步骤。 2. 掌握数据库概念模型设计,熟练绘制E-R图。 3. 掌握数据库关系...
项目数据库设计尤为重要,这里我们简单分享一下数据库设计需要注意的几点: 1、合理使用索引 2、避免或简化排序 3、消除对大型表行数据的顺序存取 4、避免相关子查询
数据库的页大小也是在数据库设计的时候就应该确定的,否则一旦实施就很难更改。对于执行随机行读写操作的OLTP(联机事务处理)应用程序,通常最好使用较小的页大小,这样不需要的行浪费的缓冲池空间就会较少。对于一...