MSSQL网页编程之SQL中的五种数据范例

这章描述如何检查和处理在MySQL数据库中的数据损坏。如果你的表损坏很多，你应该尝试找出其原因!见G.1调试一个MySQL服务器。数据|数据范例
扼要形貌一下SQL中的五种数据范例：字符型，文本型，数值型，逻辑型和日期型


字符型

VARCHARVSCHAR

VARCHAR型和CHAR型数据的这个不同是渺小的，可是十分主要。他们都是用来贮存字符串长度小于255的字符。

假设你向一个长度为四十个字符的VARCHAR型字段中输出数据BillGates。当你今后从这个字段中掏出此数据时，你掏出的数据其长度为十个字符——字符串BillGates的长度。如今假设你把字符串输出一个长度为四十个字符的CHAR型字段中，那末当你掏出数据时，所掏出的数据长度将是四十个字符。字符串的前面会被附加过剩的空格。

当你创建本人的站点时，你会发明利用VARCHAR型字段要比CHAR型字段便利的多。利用VARCHAR型字段时，你不必要为剪失落你数据中过剩的空格而费心。

VARCHAR型字段的另外一个凸起的优点是它能够比CHAR型字段占用更少的内存和硬盘空间。当你的数据库很年夜时，这类内存和磁盘空间的节俭会变得十分主要

文本型

TEXT

利用文本型数据，你能够寄存凌驾二十亿个字符的字符串。当你必要存储年夜串的字符时，应当利用文本型数据。

注重文本型数据没有长度，而上一节中所讲的字符型数据是有长度的。一个文本型字段中的数据一般要末为空，要末很年夜。

当你从HTMLform的多行文本编纂框（TEXTAREA）中搜集数据时，你应当把搜集的信息存储于文本型字段中。可是，不管什么时候，只需你能制止利用文本型字段，你就应当不合用它。文本型字段既年夜且慢，滥用文本型字段会使服务器速率变慢。文本型字段还会吃失落大批的磁盘空间。

一旦你向文本型字段中输出了任何数据（乃至是空值），就会有2K的空间被主动分派给该数据。除非删除该纪录，不然你没法发出这部分存储空间。



数值型

SQL撑持很多种分歧的数值型数据。你能够存储整数INT、小数NUMERIC、和钱数MONEY。

INTVSSMALLINTVSTINYINT
他们的区分只是字符长度：INT型数据的表数局限是从-2，147，483，647到2，147，483，647的整数SMALLINT型数据能够存储从-32768到32768的整数TINYINT型的字段只能存储从０到255的整数,不克不及用来贮存正数
一般，为了节俭空间，应当尽量的利用最小的整型数据。一个TINYINT型数据只占用一个字节；一个INT型数据占用四个字节。这看起来仿佛不同不年夜，可是在对照年夜的表中，字节数的增加是很快的。另外一方面，一旦你已创立了一个字段，要修正它是很坚苦的。因而，为平安起见，你应当展望以下，一个字段所必要存储的数值最年夜有多是多年夜，然后选择得当的数据范例。



MUNERIC

为了能对字段所寄存的数占有更多的把持，你可使用NUMERIC型数据来同时暗示一个数的整数部分和小数部分。NUMERIC型数据使你能暗示十分年夜的数——比INT型数据要年夜很多。一个NUMERIC型字段能够存储从-1038到1038局限内的数。NUMERIC型数据还使你能暗示有小数部分的数。比方，你能够在NUMERIC型字段中存储小数3.14。

当界说一个NUMERIC型字段时，你必要同时指定整数部分的巨细和小数部分的巨细。如：MUNERIC(23,0)

一个NUMERIC型数据的整数部分最年夜只能有28位，小数部分的位数必需小于或即是整数部分的位数，小数部分能够是零。

MONEYVSSMALLMONEY

你可使用INT型或NUMERIC型数据来存储钱数。可是，专门有别的两种数据范例用于此目标。假如你但愿你的网点能挣良多钱，你可使用MONEY型数据。假如你的野心不年夜，你可使用SMALLMONEY型数据。MONEY型数据能够存储从-922，337，203，685，477.5808到922，337，203，685，477.5807的钱数。假如你必要存储比这还年夜的金额，你可使用NUMERIC型数据。

SMALLMONEY型数据只能存储从-214，748.3648到214，748.3647的钱数。一样，假如能够的话，你应当用SMALLMONEY型来取代MONEY型数据，以节俭空间。

逻辑型

BIT

假如你利用复选框（CHECKBOX）从网页中汇集信息，你能够把此信息存储在BIT型字段中。BIT型字段只能取两个值：0或1。

小心，在你创立好一个表以后，你不克不及向表中增加BIT型字段。假如你盘算在一个表中包括BIT型字段，你必需在创立表时完成。

日期型

DATETIMEVSSMALLDATETIME

一个DATETIME型的字段能够存储的日期局限是从１７５３年１月１日第一毫秒到9999年12月31日最初一毫秒。

假如你不必要掩盖这么年夜局限的日期和工夫，你可使用SMALLDATETIME型数据。它与DATETIME型数据一样利用，只不外它能暗示的日期和工夫局限比DATETIME型数据小，并且不如DATETIME型数据准确。一个SMALLDATETIME型的字段可以存储从１９00年１月１日到２０７９年６月６日的日期，它只能准确到秒。

DATETIME型字段在你输出日期和工夫之前其实不包括实践的数据，熟悉这一点是主要的。

关于SQL经常使用的数据范例就先先容到这。
假如有甚么疑问和倡议，能够给小皮留言，大概EMAIL：xiaoboe-mail@email.jlu.edu.cn
因此我们看到，这些信息足够让我们对单个操作实现“逆操作”。

如果，某一版本可以提供强大的并发响应，但是没有Oracle的相应版本稳定，或者价格较贵，那么，它就是不适合的。

分区表是个亮点！从分区表也能看出微软要做大作强SQLServer的信心。资料很多，这里不详细说。但是重点了解的是：现在的SQLServer2005的表，都是默认为分区表的。因为它要支持滑动窗口的这个特性。这种特性对历史数据和实时数据的处理是很有帮助的。

是要和操作系统进行Socket通讯的场景。否则建议慎重！

你觉得我的非分区索引无法对起子分区，你可以提醒我一下呀！没有任何的提醒，直接就变成了非分区表。不知道这算不算一个bug。大家也可以试试。

多走走一此相关论坛，多看一些实例开发，多交流0经验，没什么的，我也是刚学没多久!加油

Mirror可以算是SQLServer的Dataguard了。但是能不能被大伙用起来就不知道了。

分区表效率问题肯定是大家关心的问题。在我的试验中，如果按照分区字段进行的查询（过滤）效率会高于未分区表的相同语句。但是如果按照非分区字段进行查询，效率会低于未分区表的相同语句。

sqlserver的痛苦之处在于有用文档的匮乏，很多只是表明的东西