新手，如何定义一个表中各个域的大小?

Question

我是新手，提的问题可能大家见笑了。
我在navicat中设计完数据库中表的name条目后,看到右边的type一栏，下拉框中不少的选项，有tinytext, varchar,等等。这些
多是什么意思啊？假设我设计一个标题的长度为300个英文字符，我应该如何选择？大家可以推荐我几本入门的书吗？
谢谢

Answer 1

假设我设计一个标题的长度为300个英文字符，我应该如何选择？
用TEXT类型TEXT[(M)] [CHARACTER SET charset_name] [COLLATE collation_name] A TEXT column with a maximum length of 65,535 (216 – 1) characters. 我在navicat中设计完数据库中表的name条目后,看到右边的type一栏，下拉框中不少的选项，有tinytext, varchar,等等。这些 
多是什么意思啊？可供选择的字段类型大家可以推荐我几本入门的书吗？
MYSQL的HELP

Answer 2

(1)char、varchar、text和nchar、nvarchar、ntext 
char和varchar的长度都在1到8000之间，它们的区别在于char是定长字符数据，而varchar是变长字符数据。所谓定长就是长度固定的，当输入的数据长度没有达到指定的长度时将自动以英文空格在其后面填充，使长度达到相应的长度；而变长字符数据则不会以空格填充。text存储可变长度的非Unicode数据，最大长度为2^31-1(2,147,483,647)个字符。 后面三种数据类型和前面的相比，从名称上看只是多了个字母"n"，它表示存储的是Unicode数据类型的字符。写过程序的朋友对Unicode应该很了解。字符中，英文字符只需要一个字节存储就足够了，但汉字众多，需要两个字节存储，英文与汉字同时存在时容易造成混乱，Unicode字符集就是为了解决字符集这种不兼容的问题而产生的，它所有的字符都用两个字节表示，即英文字符也是用两个字节表示。nchar、nvarchar的长度是在1到4000之间。和char、varchar比较：nchar、nvarchar则最多存储4000个字符，不论是英文还是汉字；而char、varchar最多能存储8000个英文，4000个汉字。可以看出使用nchar、nvarchar数据类型时不用担心输入的字符是英文还是汉字，较为方便，但在存储英文时数量上有些损失。 (2)datetime和smalldatetime 
datetime：从1753年1月1日到9999年12月31日的日期和时间数据，精确到百分之三秒。 
smalldatetime：从1900年1月1日到2079年6月6日的日期和时间数据，精确到分钟。 (3)bitint、int、smallint、tinyint和bit 
bigint：从-2^63(-9223372036854775808)到2^63-1(9223372036854775807)的整型数据。 
int：从-2^31(-2,147,483,648)到2^31-1(2,147,483,647)的整型数据。 
smallint：从-2^15(-32,768)到2^15-1(32,767)的整数数据。 
tinyint：从0到255的整数数据。 
bit：1或0的整数数据。 (4)decimal和numeric 
这两种数据类型是等效的。都有两个参数：p（精度）和s（小数位数）。p指定小数点左边和右边可以存储的十进制数字的最大个数，p必须是从 1到38之间的值。s指定小数点右边可以存储的十进制数字的最大个数，s必须是从0到p之间的值，默认小数位数是0。 (5)float和real 
float：从-1.79^308到1.79^308之间的浮点数字数据。 
real：从-3.40^38到3.40^38之间的浮点数字数据。在SQL Server中，real的同义词为float(24)。 数据库定义到char类型的字段时，不知道大家是否会犹豫一下，到底选char、nchar、varchar、nvarchar、text、ntext中哪一种呢？结果很可能是两种，一种是节俭人士的选择：最好是用定长的，感觉比变长能省些空间，而且处理起来会快些，无法定长只好选用定长，并且将长度设置尽可能地小；另一种是则是觉得无所谓，尽量用可变类型的，长度尽量放大些。   鉴于现在硬件像萝卜一样便宜的大好形势，纠缠这样的小问题实在是没多大意义，不过如果不弄清它，总觉得对不起劳累过度的CPU和硬盘。 下面开始了(以下说明只针对SqlServer有效)： 1、当使用非unicode时慎用以下这种查询： 
            select f from t where f = N'xx'     原因：无法利用到索引，因为数据库会将f先转换到unicode再和N'xx'比较 2、char 和相同长度的varchar处理速度差不多（后面还有说明） 3、varchar的长度不会影响处理速度！！！（看后面解释） 4、索引中列总长度最多支持总为900字节，所以长度大于900的varchar、char和大于450的nvarchar,nchar将无法创建索引 5、text、ntext上是无法创建索引的 6、O/R Mapping中对应实体的属性类型一般是以string居多，用char[]的非常少，所以如果按mapping的合理性来说，可变长度的类型更加吻合 7、一般基础资料表中的name在实际查询中基本上全部是使用like '%xx%'这种方式，而这种方式是无法利用索引的，所以如果对于此种字段，索引建了也白建 8、其它一些像re的字段则是根本不需要查询的，所以不需要索引 9、varchar的存放和string是一样原理的，即length {block}这种方式，所以varchar的长度和它实际占用空间是无关的 10、对于固定长度的字段，是需要额外空间来存放NULL标识的，所以如果一个char字段中出现非常多的NULL，那么很不幸，你的占用空间比没有NULL的大（但这个大并不是大太多，因为NULL标识是用bit存放的，可是如果你一行中只有你一个NULL需要标识，那么你就白白浪费1byte空间了，罪过罪过！），这时候，你可以使用特殊标识来存放，如：'NV' 11、同上，所以对于这种NULL查询，索引是无法生效的，假如你使用了NULL标识替代的话，那么恭喜你，你可以利用到索引了 12、char和varchar的比较成本是一样的，现在关键就看它们的索引查找的成本了，因为查找策略都一样，因此应该比较谁占用空间小。在存放相同数量的字符情况下，如果数量小，那么char占用长度是小于varchar的，但如果数量稍大，则varchar完全可能小于char，而且要看实际填充数值的充实度，比如说varchar(3)和char(3)，那么理论上应该是char快了，但如果是char(10)和varchar(10)，充实度只有30%的情况下，理论上就应该是varchar快了。因为varchar需要额外空间存放块长度，所以只要length(1-fillfactor)大于这个存放空间（好像是2字节)，那么它就会比相同长度的char快了。 13、nvarchar比varchar要慢上一些，而且对于非unicode字符它会占用双倍的空间，那么这么一种类型推出来是为什么呢？对，就是为了国际化，对于unicode类型的数据，排序规则对它们是不起作用的，而非unicode字符在处理不同语言的数据时，必须指定排序规则才能正常工作，所以n类型就这么一点好处。 
总结： 
1、如果数据量非常大，又能100%确定长度且保存只是ansi字符，那么char 
2、能确定长度又不一定是ansi字符或者，那么用nchar； 
3、不确定长度，要查询且希望利用索引的话，用nvarchar类型吧，将它们设到400； 
4、不查询的话没什么好说的，用nvarchar(4000) 
5、性格豪爽的可以只用3和4，偶尔用用1，毕竟这是一种额外说明，等于告诉别人说，我一定需要长度为X位的数据 

Answer 3

http://dev.mysql.com/doc/refman/5.1/zh/column-types.html
11. 列类型
11.1. 列类型概述
11.1.1. 数值类型概述
11.1.2. 日期和时间类型概述
11.1.3. 字符串类型概述
11.2. 数值类型
11.3. 日期和时间类型
11.3.1. DATETIME、DATE和TIMESTAMP类型
11.3.2. TIME类型
11.3.3. YEAR类型
11.3.4. Y2K事宜和日期类型
11.4. String类型
11.4.1. CHAR和VARCHAR类型
11.4.2. BINARY和VARBINARY类型
11.4.3. BLOB和TEXT类型
11.4.4. ENUM类型
11.4.5. SET类型
11.5. 列类型存储需求
11.6. 选择正确的列类型
11.7. 使用来自其他数据库引擎的列类型

Answer 4

看上去你还不了解数据库的基础,建议先读三遍《数据库系统概论》 (掌握基础知识和概念) 然后再粗略浏览一遍MYSQL的官方手册。（方便以后查找，避免类似于考试的时候，给你本政治书也不知道答案在第几章，第几页）MySQL官方文档 http://dev.mysql.com/doc/refman/5.1/zh/index.html

Answer 5

鉴于现在硬件像萝卜一样便宜的大好形势，纠缠这样的小问题实在是没多大意义，不过如果不弄清它，总觉得对不起劳累过度的CPU和硬盘。 
-----------------------
这句话的观点我不认同，因为其只仅从存储空间上的角度去考虑问题