数据库字段类型设计

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

2、int，占四个字节，取值范围是-2^31到2^31-1（大约正负二十亿）int 类型phpmyadmin默认会设置int(10)

3、bigint，占八个字节，取值范围是-2^63到2^63-1

二、时间类型

1、Date：用来存储没有时间的日期。Mysql获取和显示这个类型的格式为“YYYY-MM-DD”。支持的时间范围为“1000-00-00”到“9999-12-31”；

2、TimeStamp：存储既有日期又有时间的数据。存储和显示的格式为 “YYYY-MM-DD HH:MM:SS”。支持的时间范围是“1000-00-00 00:00:00”到“9999-12-31 23:59:59”；

3、DateTime：也是存储既有日期又有时间的数据。存储和显示的格式跟TimeStamp一样。支持的时间范围是“1970-01-01 00:00:01”到“2038-01-19 03:14:07”； （一般用这个）

1、尽量使用TINYINT、SMALLINT、MEDIUM_INT作为整数类型而非INT，如果非负则加上UNSIGNED

2、大小（VARCHAR的长度只分配真正需要的空间）

3、使用枚举或整数代替字符串类型

4、类型（尽量使用TIMESTAMP而非DATETIME，在精度要求高的应用中，建议使用定点数来存储数值，以保证结果的准确性。能用decimal就不要用float）

5、单表不要有太多字段，建议在20以内

6、值（是否允许为空、是否有默认值，尽量避免使用NULL字段，很难查询优化且占用额外索引空间）

7、用整型来存IP

8、合理的字段名(符合3NF，避免不必要的数据冗余，参考 3NF)

9、创建并使用正确的索引

10、将字段设置为not null 还出于另外一种考虑：mysql表的列中包含null的话，那么该列不会包含在所有中。也就是使用索引是无效的。所有，考虑今后会使用索引的字段，就要设置字段属性是not null。

11、如果你要保存NULL，手动去设置它，而不是把它设为默认值。

12、考虑到这个字段今后会作为查询关键字使用like的形式进行搜索。那么要将该字段定义成索引。这样使用like查询就会更快。

动态增加数据库表字段

预留足够的空白字段，运行时作动态影射

用xml格式保存在单字段里

改列为行，用另外一个表存放定制字段

【一】

现在我们来分析一下四种技术的优劣，不过首先可以排除的是第一点动态增加字段的方法，因为在实际 *** 作时候几乎是不可能的（sqlserver太慢，oracle索性不支持），基本可以不讨论就排除。剩下后三点。

【二】

先来讨论预留空白字段的方法，基本原理就是在数据库表设计的时候加入一些多余的字段，看下面的代码：

CREATE TABLE Sample(

name varchar(12),

field0 varchar(1),

field1 varchar(1),

fieldN varchar(1)

}

然后看实际运行时候的需要，动态分配字段给系统使用，也许需要一个这样的结构来描述分配情况：

public class Available

{

public int CurrentUnusedFieldNumber

public Hashtable FieldToRealName

}

也许某一时刻的数据状况是这样的： CurrentUnusedFieldNumber=3,

哈西表FieldToRealName包含内容是("field0"="SomeId", "field1"="AnyName",

"field2=IsOk")

现在的问题是如果要配合Hibernate，如何来处理？以上段的数据使用状况为例子，如果我们的类定义是这样：

public class Entity01

{

public string Name

public string SomeId

public string AnyName

public bool IsOk

}

也许只需要修改一下xxx.hbm.xml，把 SomeId 和 field0

做成对应就ok了。但是在运行时我们怎么知道会有这样的类定义？除非我们做动态代码生成，自动编译也许可以，但是问题也许就到其他方面去了；如果我们不用动态定义，那么类就只能是这样：

public class Entity01

{

public string Name

public Hashtable ExtraFieldAndValues

}

使用的时候，用 entity01.ExtraFieldAndValues.setValue("AnyName", "boss")

的方式来引用，也许这样是修改最少的了，但是问题是Hibernate不支持这样的方法。

【三】

再来讨论单字段存储的方法，我们使用这样的数据库表定义

CREATE TABLE Sample

(

Name varchar(12),

Xml CLOB(102400) // 仅作说明而已

)

然后对应这样的类定义

public class Entity01

{

public string Name

public string Xml

public Hashtable ExtraNameAndValueFromXml

}

我们的代码就可以这样使用：string id =

entity01.ExtraNameAndValueFromXml.getValue("SomeId")

了。这样解决看起来很不错，不仅不需要Available表，而且看起来Hibernate对它的支持也很完美，但是致命的问题在于：如果保持高效的查询？除非数据库系统本身对此有支持，否则就只能用低效的substring或者like做查询，这在大批量数据中根本就不可行。

是不是折衷一下，把两种方法的优点和起来？问题有来了：怎么保持两者之间数据的同步？难道要我们用存储过程去解析xml内容？

所以，一个两难的问题，需要我们认真去解决。我们通过认真的需求分析，也许可以减少可变字段的数量，但是只要有一个可变字段或者可变的可能性存在，我们始终要去解决这个两难的问题。

期待继续讨论。

【四】

还有一种方法就是改列为行，用另外一个表存放扩展字段，定义可以如下：

CREATE

TABLE SampleFields

(

idSample Integer,

fieldName varchar(30),

fieldValue varchar(100)

)

其中idSample关联到Sample表的id字段（我没有写出来）。这样的话，Hibernate很容易支持，也可以支持Sql的查询，而且可以支持把内容放到Hashtable中去，看起来是目前最好的方式了。但是在大容量数据的时候，SampleFields表的数据会是主表数据量的N倍（看定制的字段数目多少而定），同样存在有很严重的性能问题。