数据库有哪三类?

一、数字类型。

数字类型按照我的分类方法分为三类：整数类、小数类和数字类。我所谓的“数字类”，就是指DECIMAL和NUMERIC，它们是同一种类型。它严格的说不是一种数字类型，因为他们实际上是将数字以字符串形式保存的；他的值的每一位（包括小数点）占一个字节的存储空间，因此这种类型耗费空间比较大。但是它的一个突出的优点是小数的位数固定，在运算中不会“失真”，所以比较适合用于“价格”、“金额”这样对精度要求不高但准确度要求非常高的字段。

小数类，即浮点数类型，根据精度的不同，有FLOAT（单精度）和DOUBLE（双精度）两种。它们的优势是精确度，FLOAT可以表示绝对值非常小、小到约 1.17E-38 （0.000...0117， 小数点后面有37个零）的小数，而DOUBLE更是可以表示绝对值小到约 2.22E-308 （0.000...0222， 小数点后面有307个零）的小数。FLOAT类型和DOUBLE类型占用存储空间分别是4字节和8字节。如果需要用到小数的字段，精度要求不高的，当然用FLOAT了！可是说句实在话，我们“民用”的数据，哪有要求精度那么高的呢？这两种类型至今我没有用过——我还没有遇到适合于使用它们的事例。

用的最多的，最值得精打细算的，是整数类型。从只占一个字节存储空间的TINYINT到占8个字节的BIGINT，挑选一个“够用”并且占用存储空间最小的类型是设计数据库时应该考虑的。TINYINT、SMALLINT、MEDIUMINT、INT和BIGINT占用存储空间分别为1字节、2字节、3字节、4字节和8字节，就无符号的整数而言，这些类型能表示的最大整数分别为255、65535、16777215、4294967295和18446744073709551615。如果用来保存用户的年龄（举例来说，数据库中保存年龄是不可取的），用TINYINT就够了；九城的《纵横》里，各项技能值，用SMALLINT也够了；如果要用作一个肯定不会超过16000000行的表的AUTO_INCREMENT的IDENTIFY字段，当然用 MEDIUMINT 不用 INT ，试想，每行节约一个字节，16000000行可以节约10兆多呢！

二、日期时间类型

日期和时间类型比较简单，无非是 DATE、TIME、DATETIME、TIMESTAMP和YEAR等几个类型。只对日期敏感，而对时间没有要求的字段，就用DATE而不用DATETIME是不用说的了；单独使用时间的情况也时有发生——使用TIME；但最多用到的还是用DATETIME。在日期时间类型上没有什么文章可做，这里就不再详述。

三、字符（串）类型

不要以为字符类型就是 CHAR ！CHAR和VARCHAR的区别在于CHAR是固定长度，只要你定义一个字段是CHAR(10),那么不论你存储的数据是否达到了10个字节，它都要占去10个字节的空间；而VARVHAR则是可变长度的，如果一个字段可能的值是不固定长度的，我们只知道它不可能超过10个字符，把它定义为 VARCHAR(10)是最合算的，VARCHAR 类型的实际长度是它的值的(实际长度+1)。为什么“+1”呢？这一个字节用于保存实际使用了多大的长度呀！从这个“+1”中也应该看到，如果一个字段，它的可能值最长是10个字符，而多数情况下也就是用到了10个字符时，用VARCHAR就不合算了：因为在多数情况下，实际占用空间是11个字节，比用CHAR(10)还多占用一个字节！

举个例子，就是一个存储股票名称和代码的表，股票名称绝大部分是四个字的，即8个字节；股票代码，上海的是六位数字，深圳的是四位数字。这些都是固定长度的，股票名称当然要用 CHAR(8) ；股票代码虽然是不固定长度，但如果使用VARVHAR(6)，一个深圳的股票代码实际占用空间是5个字节，而一个上海的股票代码要占用7个字节！考虑到上海的股票数目比深圳的多，那么用VARCHAR(6)就不如CHAR(6)合算了。

虽然一个CHAR或VARVHAR的最大长度可以到255，我认为大于20的CHAR是几乎用不到的——很少有大于20个字节长度的固定长度吧？不是固定长度的就用VARCHAR！大于100的VARCHAR也是几乎用不到的——比这更大的用TEXT就好了。TINYTEXT，最大长度为255，占用空间也是(实际长度+1)；TEXT，最大长度65535，占用空间是(实际长度+2)；MEDIUMTEXT，最大长度16777215，占用空间是(实际长度+3)；LONGTEXT，最大长度4294967295，占用空间是(实际长度+4)。为什么“+1”？“+2”？“+3”？“+4”？你要是还不知道就不应该了。这些可以用在论坛啊、新闻啊，什么的，用来保存文章的正文。根据实际情况的不同，选择从小到大的不同类型。

四、枚举和集合类型

枚举（ENUM）类型，最多可以定义65535种不同的字符串从中做出选择，只能并且必须选择其中一种，占用存储空间是一个或两个字节，由枚举值的数目决定；集合（SET）类型，最多可以有64个成员，可以选择其中的零个到不限定的多个，占用存储空间是一个到八个字节，由集合可能的成员数目决定。

Access，MSDE 2000，Embedded Firebird，SQLite等都是可以免费再分发（free redistributable）的数据库。

相比而言，MSDE 2000 显著缺点是需要安装，最大优点是和服务器端的 SQL Server 编程模型一致，开发便利。

Access的显著缺点是功能较少，不支持事务等常用功能，最大优点是简单、多数开发者都很熟悉，部署也很方便。

SQLite支持事务，也是一款单文件数据库，比较不足的是 .NET Data Provider 还不是很成熟。

Firebird则同时具有：单文件、部署简单不需安装（只需 XCOPY 两个文件）、支持事务、存储过程、触发器，.NET Data Provider比较稳定成熟等优点。

这个星球上的数据库实在不胜枚举，这里只列一些我接触过的常见的。

可以稍微夸张点说，有交互的应用，起码得用一下数据保存，即便是自定义结构的数据保存，还是最常见的INI、XML等，都可以算是“数据库”，真正点的，如DBase系列、FoxBase、FoxPro、MSAccess、InterBase、MS SQL Server、Oracle、DB2等，这些是商业化的数据库，前面几个只能算是数据库，后面几个是RMDBS（关系型数据库管理系统）。

对应商业化的，有开源的：SQLite、SimpleSQL、Berkely DB、Minosse、Firebird( 前身是是Borland公司的InterBase)、PostgreSQL、MySQL等。

□SQLite：大家可以看我的SQLite系列随笔，C编写的，可以跨 *** 作平台，支持大部分ANSI SQL 92，它是嵌入式的轻量级关系形数据库引擎，只需要一个DLL，体积为250k，数据库也只是一个文件，零配置，便可工作。既然开源，你甚至可以把它嵌入你的程序中。核心开发人员只有一个，最近加入了另外一个，也就是2个人而已，实在佩服，目前发展到3.1.0，相当高效稳定，有开源驱动在sourceforge.net上有其ADO.NET Data Provider for SQLite ：https://sourceforge.net/projects/adodotnetsqlite/ 。

□SimpleSQL：相对SQLite要大几倍，但也是轻量级的，功能稍微强大一点，C++编写，有OLE、Java等版本。

□Berkely DB：C++编写的大型关系型数据库系统，还额外地支持XML(把XML当成数据库)，号称2百万的安装量，MySQL也只不过号称5百万安装量而已，跨平台。

□Minosse：纯C#编写的大型关系型数据库系统，理想是超越MS SQL Server！最新版本：0.2.0，真难得，纯Java写的看得多了，纯C#的，不是移植别人的，还是第一个，佩服作者：包含C/S和嵌入式版本，并可跨越大部分平台，因为它不用Windows的东西，可以在Mono下编译。

□Firebird：这个东西太牛了，目前有1.5稳定版本已经拥有大量特性，完全支持ANSI SQL92、98等，一些超酷的特性让人疯狂(1.0特性、1.5特性，从这里开始研究)，主要开发人员是一个俄罗斯人，目前开发队伍已经扩大到近100人，有3种模式，单机独立，典型C/S，超级服务器。2.0版本和3.0版本将在近期推出，看完其路线图(2.0、3.0)你就会疯掉。有.NET驱动，目前是1.7beta版。主要特性：

◆A.C.I.D；

◆MGA(任何版本的引擎都可以处理同一数据库记录)；

◆PSQL(存储过程)超级强大，ms sql相对的太次，它啥都能在服务器端实现并推送到客户端成为强大的报表，存储过程；

◆触发器都可以在客户端获取监控追踪；

◆自动只读模式；

◆创新的事务保证绝对不会出错；

◆24*7运行中仍然可以随时备份数据库；

◆统一触发器：任何 *** 作都可以让某表唯一的触发器来总控；

◆大部分语言都可以写plug-in，并直接在存储过程中调用函数；

◆c->c++，更加少的代码但更加快的速度；

◆3种运行模式，甚至可以嵌入式；

◆主流语言都可以调用它；

◆动态sql执行；

◆事务保存点；

□PostgreSQL：POSTGRES数据库的后开源版本，号称拥有任何其他数据库没有的大量新特性，似乎目标是要做超大型的OO关系型数据库系统，目前已经发展到8.0，有.NET驱动，中文官方网站有详细介绍。

□MySQL：这个，不用说了吧？号称全球最受欢迎的开源数据库，但让我奇怪的是，PostgreSQL都有简体中文的支持：包括内核、管理工具、QA等等，在最新版本MySQL中，我却没有发现... ，有.NET驱动，其中MySQL Connector/Net就是原来在sf.net上的ByteFX.Data项目，作者已经加入了MySQL团队，参看《感慨 20 之开源的前途/钱图？（1数据库）》。

======================================================

最近在学习 Firebird Embeded Database。作为一款单文件型小型数据库，Firebird 具有很多吸引人的特征，比如支持事务、支持存储过程、触发器等，而且 Embeded 版本的 Firebird 在 .NET 开发中只需要拷贝两个文件：一个 fbembed.dll （非托管但不需要注册的动态链接库）和一个 ADO.NET Data Provider 的 FirebirdSql.Data.Firebird.dll。这些特征都非常适合那些需要在客户端存储一些数据，但又不想安装数据库（比如MSDE）软件的情形。

据称，在国外，需要使用客户端数据库的情况中，有30%左右的开发者选择Access，有30%的开发者选择MSDE 2000，有30%的开发者选择Embedded Firebird，剩余10%选择其他小型数据库，如SQLite，MySQL 等。

上面所说的Access，MSDE 2000，Embedded Firebird，SQLite等都是可以免费再分发（free redistributable）的数据库。相比而言，MSDE 2000 显著缺点是需要安装，最大优点是和服务器端的 SQL Server 编程模型一致，开发便利。Access的显著缺点是功能较少，不支持事务等常用功能，最大优点是简单、多数开发者都很熟悉，部署也很方便。SQLite支持事务，也是一款单文件数据库，比较不足的是 .NET Data Provider 还不是很成熟。Firebird则同时具有：单文件、部署简单不需安装（只需 XCOPY 两个文件）、支持事务、存储过程、触发器，.NET Data Provider比较稳定成熟等优点。

Firebird 本身有SuperServer和Embedded版本之分，后者只能本机访问，不接受TCP连接。对于开发者而言，从Embedded数据库切换到SuperServer，只需更改数据库连接串中的ServerType值就行。

但是，在你正式决定使用?Firebird 之前，请你注意下面这个 known issue（已知问题）： Firebird 数据库文件不能放置在含有中文等字符的路径中。Firebird 的文件名不可以用中文字符，所在路径的任何部分如果含有中文字符，都将无法访问到数据库。举个例子，中文Windows桌面所在的目录一般是“C:\Documents and Settings\用户名\桌面”，如果数据库文件放置在桌面上，就无法访问到。当然，Firebird 内部是可以存储中文字符的，因为它支持 GB2312 和 UNICODE 等字符集。

需要注意一点，连接串中的 Database 地址如果使用相对路径，请一定注意这个相对路径是相对于 fbembed.dll 所在目录的。

1、数据库：32767个数据库，最小为1MB，最大为1TB。

2、表：每个数据库最多有20亿个表。

3、列：每个表最多1024列，每列的最大字节数为8060(文本和图像列除外)。

SQL Server 的每个数据库最多可存储 20 亿个表，每个表可以有 1024 列。表的行数及总大小仅受可用存储空间的限制。每行最多可以存储 8,060 字节。如果创建具有 varchar、nvarchar 或 varbinary 列的表，并且列的字节总数超过 8,060 字节，虽然仍可以创建此表，但会出现警告信息。如果试图插入超过 8,060 字节的行或对行进行更新以至字节总数超过 8,060，将出现错误信息并且语句执行失败。

---