数据库设计字段类型设置经验

将过去在开发中体会到经验整理出来。今天贴出来,整理,做个备忘。

 

 

 

tinyint 是-128到128 。当属性设置为unsigned的时候。最大值就是255了。现在知道为什么需要设置为unsigned属性了。原来是为了最大限度的使用给予的存储空间。如果不设置。那么假如你的值都是正数的。那么-128这一百多个数字就相当于是浪费了。
tinyint会自动设置为tinyint(3)
smallint  不设置unsigned的时候,也有3万多的样子。

tinytext 就是255个字节。大概就是存储127个中文的样子 tinytext就相当于varchar类型。把它看成这样的该类型就容易理解了。

int 类型phpmyadmin默认会设置int(10)

概念纠正:原来一直以为这里的10表示位数。直到有次想保存1101061021496,结果在字段中的值都变成了:4294967295。 看MySQL手册上说:

(int后面括号的数字)显示宽度并不限制可以在列内保存的值的范围,也不限制超过列的指定宽度的值的显示。
int的范围:-2147483648到2147483647。刚好是10个位,那么就是数十亿级别的数字。数据库设计经验:像订单的值非常大。不确定,如果达到10位数,还不如使用varchar类型。fangwei就没有使用int,而是varchar类型

从上面也告诉我一个经验:如果保存在数据库的值都变成一样的。也就是无论我是1101061021496 还是1101061021569,结果都变成了固定的值,比如4294967295。那么可以考虑确认是否是数据库该字段的范围问题。这样的问题出现过好几次了。就是没有掌握思路。导致浪费了不少时间。

将字段设置为not null 还出于另外一种考虑:mysql表的列中包含null的话,那么该列不会包含在所有中。也就是使用索引是无效的。所有,考虑今后会使用索引的字段,就要设置字段属性是not null。
如果你要保存NULL,手动去设置它,而不是把它设为默认值。

考虑到这个字段今后会作为查询关键字使用like的形式进行搜索。那么要将该字段定义成索引。这样使用like查询就会更快。
现在终于体会到到国外作者书籍上提到:设计数据库之前要问自己,之后会查询哪些数据。  考虑了这些,以后有什么查询需要。结构都能适应了。

//////////////////////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////////////////////////

2011.1.19 关于设计大流量网站数据库,会员分表或者分库的设计考虑:

主键不要设为自增型。设置为自增型的后果就是:今后无法分离在不同的mysql数据库服务器上。比如id编号由于是自增的,所以两个数据库中可能会出现用户编号都是10005的情况。

但是,mysql主键会自动设置为自增型。可以用另外一个字段来作为标识符。而不是自增型id号。方法:新增一个字段作为行的标识符。具体设计:一个表做两个字段,一个是id作为主键,自增型,另外一个是uid,作为用户的标识。

程序判断上,是以uid作为判断用户的依据。而不是id主键作为判断依据(程序上的失误,改动比起数据库设计失误改动容易得多。因为你数据已经入库了。在修改起来就比较难了)
//////////////////////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////////////////////////

时间: 2024-09-20 06:26:57

数据库设计字段类型设置经验的相关文章

asp在线实现修改access数据库的字段类型

数据|数据库|在线|access|字段类型 阿里西西(alixixi.com)在做一个客户项目的时候,程序已经交付并上传到客户的网通空间,但我们的开发团队使用的是电信线路,进行几十M大小的数据传输是非常的慢. 在一个调整中,因为字段设计得太短,需要修改数据库的字段类型,但数据库非常大,如果下载的话,估计半天才能下载完,修改完成还在再上传... 于是,决定通过在线修改AC库的字段,查了些资料,写出了以下代码,轻松实现了把原来文本类型的字段改成了备注型,一切问题解决! 以下代码可以提供给大家参考,把

数据库设计中的小经验

http://www.cnblogs.com/guojingyang/archive/2008/11/26/1341406.html   1. 原始单据与实体之间的关系 可以是一对一.一对多.多对多的关系.在一般情况下,它们是一对一的关系:即一张原始单据对应且只对应一个实体.在特殊情况下,它们可能是一对多或多对一的关系,即一张原始单证对应多个实体,或多张原始单证对应一个实体.这里的实体可以理解为基本表.明确这种对应关系后,对我们设计录入界面大有好处.[例1]:一份员工履历资料,在人力资源信息系统

请教mysql日期字段类型设置与C#DataTable配合的问题

问题描述 在mysql中有日期字段,我设置该字段类型为DateTime时,在C#执行查询并写入DataTable时,报错误:该字符串未被识别为有效的DateTime.该字段的值为:2014/8/2014:38:09,也尝试将/改为-,都一样报错.报错的语句为:CurrlicTatatable=db.ExecuteDataTable(sqlinfo,null);经验证,sql语句没有错误,主要问题出在字段类型的设置上.现向各位大神请教mysql中的时间字段正确设置. 解决方案 解决方案二:不用拼接

当数据库中字段设计为smalint或者tinyint后,程序中要求字段为枚举型,应该怎么设置

我们知道枚举默认和int类型是可以直接强转换的,并不会出现任何错误,但对于其它类型来说, 有可能会有问题,比如,一个enum类型, 如下声明会有错误 enum ProductColumns {   ProductId=1, . . . Status=4294967297, } OK,这样的话,程序会报错,因为它已经超过了int型的范围(int型其实就是Int32结构体类型,32表示最大存储的整型范围是2的32次方) 修改程序为 enum ProductColumns:long { } 让它继承l

[数据库技术]SQL数据库设计经验

设计|数据|数据库|数据库设计 一个成功的管理系统,是由:[50% 的业务 + 50% 的软件] 所组成,而 50% 的成功软件又有 [25% 的数据库 + 25% 的程序] 所组成,数据库设计的好坏是一个关键.如果把企业的数据比做生命所必需的血液,那么数据库的设计就是应用中最重要的一部分.有关数据库设计的材料汗牛充栋,大学学位课程里也有专门的讲述.不过,就如我们反复强调的那样,再好的老师也比不过经验的教诲.所以我归纳历年来所走的弯路及体会,并在网上找了些对数据库设计颇有造诣的专业人士给大家传授

数据库设计经验

设计|数据|数据库|数据库设计 一个成功的管理系统,是由:[50% 的业务 + 50% 的软件] 所组成,而 50% 的成功软件又有 [25% 的数据库 + 25% 的程序] 所组成,数据库设计的好坏是一个关键.如果把企业的数据比做生命所必需的血液,那么数据库的设计就是应用中最重要的一部分.有关数据库设计的材料汗牛充栋,大学学位课程里也有专门的讲述.不过,就如我们反复强调的那样,再好的老师也比不过经验的教诲.所以我归纳历年来所走的弯路及体会,并在网上找了些对数据库设计颇有造诣的专业人士给大家传授

实践出真知 有关数据库设计经验简介

如果将数据库设计比作是福尔摩斯破案,根据各种条件,限制,规则,抽丝拨茧,寻找其中的相互联系,一步一步深入案件的中间,最终解决案件.但破案首先需要有方法,那么对于数据库设计目前以使用已久的一系列设计数据库结构的成熟方法(比如:规范化)都可以作为破案所需方法的良好的根基.实际上,这些方法几乎都是经典的设计方法,因此,在进行数据库设计的时候,遵循这些方法并不会感觉到太困难.正如同我们所知,我们可以直接将你按方法的设计可以直接转变成SQL SERVER表.但是,除非你只是为了抓一个现显的小偷,否则需要各

数据库设计的一点经验

设计|数据|数据库|数据库设计 1.字段最好都要采用默认值,除非那些自动增长型或主键 外键.字符类型都默认 空字符串,数值型都默认 0 ,日期型默认为系统日期.这样做,好处是:减少程序不必要的代码,减少程序代码的长度,从而减少程序出错的可能.比如在一个表含有 20 个字段,我们在将某一行的数据读出到相应的控件里,就需要判断其是否为空.那么,如果不采用默认值,则将要增加相应的判断语句,程序的长度就可能增加 60 行. 2 字段的长度设计要考虑到将来变化的需要,长度一般要比需求分析的长度长两个单位.

Mysql数据库Char和Varchar字段类型长度的选择比较

  网上有很多关于char和varchar的相关比较,但是都历史悠久,这里转载一篇信息比较新的,个人认为对我的设计字段决定帮助很大. 现代数据库一般都支持CHAR与VARCHAR字符型字段类型,CHAR是用来保存定长字符,存储空间的大小为字段定义的长度,与实际字符长度无关,当输入的字符小于定义长度时最后会补上空格.VARCHAR是用来保留变长字符,在数据库中存储空间的大小是实际的字符长度,不会像CHAR一样补上空格,这样占用的空间更少. 从以上特点来看,VARCHAR比CHAR有明显的优势,因此