zoukankan      html  css  js  c++  java
  • 数据库数据类型选择

    char 和 varchar

      一是根据字符的长度来判断。在实际项目中,如果某个字段的字符长度比较短此时一般是采用固定字符长度。(问:多少算不短)(如某个字段,像人的名字,其最长的长度也是有限的。如我们给其分配18个字符长度即可。此时虽然每个人的名字长度有可能不同,但是即使为其分配了固定长度的字符类型,即18个字符长度,最后浪费的空间也不是很大。而如果采用NVARCHAR数据类型时,万一以后需要改名,而原先的存储空间不足用来容纳新的值,反而会造成一些额外的工作。在这种情况下,进行均衡时,会认为采用CHAR固定长度的数据类型更好。)

      二是考虑其长度的是否相近。如果某个字段其长度虽然比较长,但是其长度总是近似的,如一般在90个到100个字符之间,甚至是相同的长度。此时比较适合采用CHAR字符类型。比较典型的应用就是MD5哈希值。当利用MD5哈希值来存储用户密码时,就非常使用采用CHAR字符类型。因为其长度是相同的。另外,像用来存储用户的身份证号码等等,一般也建议使用CHAR类型的数据。

      三是从碎片角度进行考虑。使用CHAR字符型时,由于存储空间都是一次性分配的。为此某个字段的内容,其都是存储在一起的。单从这个角度来讲,其不存在碎片的困扰。而可变长度的字符数据类型,其存储的长度是可变的。当其更改前后数据长度不一致时,就不可避免的会出现碎片的问题。故使用可变长度的字符型数据时,数据库管理员要时不时的对碎片进行整理。如执行数据库导出导入作业,来消除碎片。

      四是即使使用Varchar数据类型,也不能够太过于慷慨。这是什么意思呢?如现在用户需要存储一个地址信息。根据评估,只要使用100个字符就可以了。但是有些数据库管理员会认为,反正Varchar数据类型是根据实际的需要来分配长度的。还不如给其大一点的呢。为此他们可能会为这个字段一次性分配200个字符的存储空间。这VARCHAR(100)与VARCHAR(200)真的相同吗?结果是否定的。虽然他们用来存储90个字符的数据,其存储空间相同。但是对于内存的消耗是不同的。对于VARCHAR数据类型来说,硬盘上的存储空间虽然都是根据实际字符长度来分配存储空间的,但是对于内存来说,则不是。其时使用固定大小的内存块来保存值。简单的说,就是使用字符类型中定义的长度,即200个字符空间。显然,这对于排序或者临时表(这些内容都需要通过内存来实现)作业会产生比较大的不利影响。所以如果某些字段会涉及到文件排序或者基于磁盘的临时表时,分配VARCHAR数据类型时仍然不能够太过于慷慨。还是要评估实际需要的长度,然后选择一个最长的字段来设置字符长度。如果为了考虑冗余,可以留10%左右的字符长度。千万不能认为其为根据实际长度来分配存储空间,而随意的分配长度,或者说干脆使用最大的字符长度。

    选择char还是选择varchar的建议

            (1) 适宜于char的情况:

            a. 列中的各行数据长度基本一致,长度变化不超过50字节;

            b. 数据变更频繁,数据检索的需求较少。

            c. 列的长度不会变化,修改char类型列的宽度的代价比较大。

            d. 列中不会出现大量的NULL值。

            e. 列上不需要建立过多的索引,过多的索引对char列的数据变更影响较大。

            (2) 适宜于archar的情况;

            a. 列中的各行数据的长度差异比较大。

            b. 列中数据的更新非常少,但查询非常频繁。

            c. 列中经常没有数据,为NULL值或为空值。

  • 相关阅读:
    在osg的图形上贴一张纹理图片
    在vs下的osg的qt窗口开发例子以及一些注意事项
    几个排序算法
    UVa11988-破损的键盘 Broken Keyboard
    UVa 442-矩阵链乘 Matrix Chain Multiplication
    Uva 514-铁轨 Rails
    Uva 136-丑数 ugly number
    修改 Sublime 按快捷键 ctrl+s 自动格式化(reindent lines)的问题
    React Native 项目配置 Flow (windows环境)
    Redux-Form 基础使用
  • 原文地址:https://www.cnblogs.com/zhangchaoran/p/7269091.html
Copyright © 2011-2022 走看看