甜橘子，专注成都网站制作网站设计与营销型网站建设与优化
QQ :532337155
电话：028-86922220
insert into 表名 (DATE型字段名) values(to_date('2013-01-31 06:59:44','yyyy-mm-dd hh24:mi:ss')) ;
创新互联是专业的公主岭网站建设公司，公主岭接单;提供成都做网站、成都网站制作,网页设计,网站设计,建网站,PHP网站建设等专业做网站服务;采用PHP框架,可快速的进行公主岭网站开发网页制作和功能扩展;专业做搜索引擎喜爱的网站,专业的做网站团队,希望更多企业前来合作!
概述
通过实例 全面而深入的分析oralce的基本数据类型及它们的存储方式 以ORACLE G为基础 介绍oralce g引入的新的数据类型 让你对oracle数据类型有一个全新的认识 揭示一些不为人知的秘密和被忽略的盲点 从实用和优化的角度出发 讨论每种数据类型的特点 从这里开始oracle之旅！
第一部份 字符类型
§ char
定长字符串 会用空格来填充来达到其最大长度 最长 个字节
． 新建一个测试表test_char 只有一个char类型的列 长度为
SQL create table test_char(colA char( ));
Table created
． 向这个表中插入一些数据
SQL insert into test_char values( a );
row inserted
SQL insert into test_char values( aa );
row inserted
SQL insert into test_char values( aaa );
row inserted
SQL insert into test_char values( aaaa );
row inserted
SQL insert into test_char values( aaaaaaaaaa );
row inserted
注意 最多只能插入 个字节 否是就报错
SQL insert into test_char values( aaaaaaaaaaa );
insert into test_char values( aaaaaaaaaaa )
ORA : value too large for column PUB_TEST TEST_CHAR COLA (actual: maximum: )
． 使用dump函数可以查看每一行的内部存数结构
SQL select colA dump(colA) from test_char;
COLA DUMP(COLA)
a Typ= Len= :
aa Typ= Len= :
aaa Typ= Len= :
aaaa Typ= Len= :
aaaaaaaaaa Typ= Len= :
注意 Typ= 表示数据类型的ID Oracle为每一种数据类型都进行了编号 说明char类型的编号是
Len = 表示所在的内部存储的长度(用字节表示) 虽然第一例只存了一个字符 a 但是它还是占用了 个字节的空间
表示内部存储方式 可见oracle的内部存储是以数据库字符集进行存储的
正好是字符a的ASCII码
可以使用chr函数把ASCII码转成字符
SQL select chr( ) from dual;
CHR( )
a
要想知道一个字符的ASCII码 可以使用函数ascii
SQL select ascii( a ) from dual;
ASCII( A )
正好是空格的ascii码值
Char类型是定长类型 它总会以空格来填充以达到一个固定宽度
使用char类型会浪费存储空间
Oracle的数据类型的长度单位是字节
SQL select dump( 汉 ) from dual;
DUMP( 汉 )
Typ= Len= :
可见一个汉字在oracle中是占用了两个字节的
英文字母或符号只占用一个字节
Char( )最多可存放 个汉字
§ varchar
是一种变长的字符类型 最多可占用 字节的存储空间
创建一个表 只有一列 类型为varchar 长度为
SQL create table test_varchar( col varchar ( ));
Table created
插入一些数据
SQL insert into test_varchar values( a );
row inserted
SQL insert into test_varchar values( aa );
row inserted
SQL insert into test_varchar values( aaa );
row inserted
SQL insert into test_varchar values( aaaaaaaaaa );
row inserted
SQL insert into test_varchar values( aaaaaaaaaaa );
用dump函数查看每一行的内部存储结构
SQL select col dump(col) from test_varchar;
COL DUMP(COL)
a Typ= Len= :
aa Typ= Len= :
aaa Typ= Len= :
aaaaaaaaaa Typ= Len= :
Typ= 说明varchar 类型在oracle中的类型编号为
Len代表了每一行数据所占用的字节数
后面是具体的存储值
由此可见 varchar 是存多少就占用多少空间 比较节省空间的 不会像char那样用空格填充
§ byte 和char
在 g中 字符类型的宽度定义时 可以指定单位
Byte就是字节
Char就是字符
Varchar ( byte) 长度为 个字节
Varchar ( char) 长度为 个字符所占的长度
Char( byte)长度为 个字节
Char( char) 长度为 个字符所占的长度
一个字符占用多少个字节 是由当前系统采用的字符集来决定的
如一个汉字占用两个字节
查看当前系统采用的字符集
SQL select * from nls_database_parameters where parameter = NLS_CHARACTERSET ;
PARAMETER VALUE
NLS_CHARACTERSET ZHS GBK
如果在定义类型时 不指定单位 默认是按byte 即以字节为单位的
采用char为单位的好处是 使用多字节的字符集
比如 在ZHS GBK字符集中 一个汉字占用两个字节
把数据表的某一列长度定义为可存放 个汉字 通过下面的定义就可以了
Create table test_varchar(col_char varchar ( char));
这样相对简单一些 在数据库表设计时需要注意
继续实验 新建一个表 包含两列 一列采用byte为单位 一列采用char为单位
SQL create table test_varchar (col_char varchar ( char) col_byte varchar ( byte));
Table created
Col_char列 定义为可存放 个字符
Col_byte 列 定义为可存放 个字节的字符
当前的系统采用字符集为ZHS GBK 所以一个字符占两个字节
试着在表中插入一些数据
SQL insert into test_varchar values( a a );
row inserted
SQL insert into test_varchar values( 袁 a );
row inserted
SQL insert into test_varchar values( 袁袁袁袁袁袁袁袁袁袁 aaaaaaaaaa );
row inserted
SQL insert into test_varchar values( 袁袁袁袁袁袁袁袁袁袁 袁袁袁袁袁袁袁袁袁袁 );
insert into test_varchar values( 袁袁袁袁袁袁袁袁袁袁 袁袁袁袁袁袁袁袁袁袁 )
ORA : value too large for column PUB_TEST TEST_VARCHAR COL_BYTE (actual: maximum: )
第一次 在两列中都插入字符a
第二次 在col_char列插入字符 袁 在col_byte插入字符a
第三次 在col_char列中插入 个中文字符 袁 在col_byte插入 个字符a
第四次 在两列中都插入中文字符 袁 时 报错了 第二列长度不够
再看看每一行的存储结构
SQL select col_char dump(col_char) from test_varchar ;
COL_CHAR DUMP(COL_CHAR)
a Typ= Len= :
袁 Typ= Len= :
袁袁袁袁袁袁袁袁袁袁 Typ= Len= :
当我们在col_char列插入 个汉字时 它的长度为
尽管我们在定义的时候是采用varchar ( char)
由此可见 oracle是根据当前数据库采用的字符集 每个字符的所占字节数 X 字段长度来决定了该字段所占的字节数
在本例中 varchar ( char)相当于varchar ( )
不信 我们可以试试看
SQL desc test_varchar ;
Name Type Nullable Default Comments
COL_CHAR VARCHAR ( ) Y
COL_BYTE VARCHAR ( ) Y
当采用多字节的字符集时 定义字段长度还是采用char为单位指定为佳 因为可以避免字段长度的问题
当不知道当前数据库采用的字符集 一个字符占用多少字节时 可以使用lengthb函数
SQL select lengthb( 袁 ) from dual;
LENGTHB( 袁 )
§ char还是varchar
新建一个表 一列为char类型 一列为varchar 类型
SQL create table test_char_varchar(char_col char( ) varchar_col varchar ( ));
Table created
向该表中的两列都插入相关的数据
SQL insert into test_char_varchar values( Hello World Hello World );
row inserted
SQL select * from test_char_varchar;
CHAR_COL VARCHAR_COL
Hello World Hello World
以char_col列为条件查询
SQL select * from test_char_varchar where char_col = Hello World ;
CHAR_COL VARCHAR_COL
Hello World Hello World
以varchar_col列为条件查询
SQL select * from test_char_varchar where varchar_col = Hello World ;
CHAR_COL VARCHAR_COL
Hello World Hello World
似乎char 和varchar类型没有什么两样 再看看下面的语句
SQL select * from test_char_varchar where varchar_col =char_col;
CHAR_COL VARCHAR_COL
这已经看出他们并不一样 这涉及到字符串比较的问题
因为已经发生了隐式转换 在与char列char_col进行比较时 char_col列的内容已经转换成了char( ) 在Hello World后面以空格进行填充了 而varchar_col列并没有发生这种转换
如果要让char_col列与varchar_col列相等 有两种方法
第一种是 使用trim把char_col列的空格去掉
第二种是 使遥rpad把varchar_col列用空格进行填充长度为 的字符
SQL select * from test_char_varchar where trim(char_col) = varchar_col;
CHAR_COL VARCHAR_COL
Hello World Hello World
SQL select * from test_char_varchar where char_col = rpad(varchar_col );
CHAR_COL VARCHAR_COL
Hello World Hello World
如果使用trim函数 如果char_col列上有索引 那么索引将不可用了
lishixinzhi/Article/program/Oracle/201311/17771
oracle 关于数字存储的主要有下面几个：
NUMBER(P,S) 数字类型 P为整数位，S为小数位
DECIMAL(P,S) 数字类型 P为整数位，S为小数位
INTEGER 整数类型 小的整数
FLOAT 浮点数类型 NUMBER(38)，双精度
REAL 实数类型 NUMBER(63)，精度更高
没有这种数据类型
这种的话你可以直接采用
varchar2(5)--这个5就是字段长度，包括2位小时，2位分钟，1位是那个冒号
商品图片，用户上传的头像，其他方面的图片。目前业界存储图片有两种做法：
1、 把图片直接以二进制形式存储在数据库中
一般数据库提供一个二进制字段来存储二进制数据。比如MySQL中有个blob字段。Oracle数据库中是blob或bfile类型
2、 图片存储在磁盘上，数据库字段中保存的是图片的路径。
一、图片以二进制形式直接存储在数据库中
第一种存储实现(PHP语言)：
大体思路：
1、将读取到的图片用php程序转化成二进制形式。再结合insert into 语句插入数据表中的blob类型字段中去。
3、 从数据库取出图片展示的时候。则是直接发送图片内容
4、
$row=mysql_fetch_object($result);
Header( "Content-type: image/gif");
echo $row-this_image;
实现代码如下：
$PicturePath = ‘/tmp/xxxjgjgj.jpg’;//假设这是上传的图片，php放在一个临时文件夹。脚本执行完毕后自动删除了。
$imgStream = fread(fopen($PicturePath, "r");
$blob_img = fread(fopen($imgStream, "r"), filesize($PicturePath));
$sql =” INSERT INTO Images (this_image) VALUES ($blob_img)";
注：this_image就是数据表中一个blob字段类型的字段
================取出展示图片代码
$result=mysql_query("SELECT * FROM Images WHERE PicNum=$PicNum") or die("Cant perform Query");
$row=mysql_fetch_object($result);
Header( "Content-type: image/gif");
echo $row- this_image;
总结：处理代码感觉还真比较麻烦。其实，我从来没用过在数据库中以二进制存储图片的做法。我们用得更多的是存储图片的路径，实际图片是在磁盘上保存的(图片二进制放到数据库,把数据库的负担弄重了)。
据我了解，互联网环境中，大访问量，数据库速度和性能方面很重要。一般在数据库存储图片的做法比较少，更多的是将图片路径存储在数据库中，展示图片的时候只需要连接磁盘路径把图片载入进来即可。因为图片是属于大字段。一张图片可能1m到几m。
有个原则：图片尽量不要存储在数据库中(是指不要二进制形式保存到字段，而只保存图片的路径)。这样的大字段数据会加重数据库的负担，拖慢数据库。在大并发访问的情况下很重要。这是一个经验。去看看dba对数据库性能调优方面的分析都能得到这个答案的：就是图片不要存储在数据库中。
就像这个规则一样：文章分为标题、作者、添加时间、更新时间、文章内容、文章关键字
文章内容一般是比较长的。经常使用text字段去存储。文章的内容就属于大字段。一般文章内容可以拆分到单独一个表中去。不要与文章信息存储在一张表里面。
我理解的原理是：mysql中一张表的数据是全部在一个数据文件中的。如果大字段的数据也存储在里面。程序展示列表，比如文章列表。这个时候根本不需要展示文章内容的。但是仍然会影响速度，数据库查找数据其实就是扫描那个数据文件，文件容量越小，速度就会越快(为什么单表的容量在1g-2g的时候基本上要分表了)。拆分出去到一张单独的表，就是单独的文件了。我觉得，举一反三，相互独立，分离的思想不仅在系统开发中用到，在现实生活中经常存在的。相互混合，就会造成相互影响。小巧，简洁是一种思想。
可以看看这篇翻译的文章，
http//developer.51cto.com/art/201211/364472.htm
作者建议，三种东西永远不要放到数据库里,图片，文件，二进制数据。作者的理由是，
对数据库的读/写的速度永远都赶不上文件系统处理的速度
数据库备份变的巨大，越来越耗时间
对文件的访问需要穿越你的应用层和数据库层
把图片缩略图存到数据库里？很好，那你就不能使用nginx或其它类型的轻量级服务器来处理它们了。
给自己行个方便吧，在数据库里只简单的存放一个磁盘上你的文件的相对路径，或者使用S3（备注：亚马逊云服务）或CDN之类的服务。
============================================================
关于mysql中的blob类型
bolb像int型那样，分为blob、MEDIUMBLOB、LONGBLOB。其实就是从小到大，
blob 容量为64KB ，MEDIUMBLOB 容量为16M，LONGBLOB 容量为4G。
说实话，图片用这样子存储用得还真少。使用php函数serialize进行序列化的值，我看到有人存入这个字段中去。
php手册：serialize返回字符串，此字符串包含了表示 value 的字节流，可以存储于任何地方。
mysql中blob字段存储图片有个通信大小的设置：
图片要传输给mysql存储起来，那么需要涉及到数据通信。mysql中有个配置是限制通信数据大小的。
my.conf配置文件中的max_allowed_packet，mysql默认的值是1M。
好多图片尤其是原始图可能不止1m。传输的数据(也就是图片)超过这个设置大小。结果就会出错
呵呵，限制挺多。感觉好麻烦。这样子明显占用与mysql交互的通信时间嘛。延长响应时长了。我直接丢个图片路径”images/xxxx”给mysql。没这么耗费资源。
其实所谓的性能，最关键是数据库性能。因为随着数据库数据量增大，大部分时间耗费是在php，Java等语言等待数据库返回数据的过程中耗费时间。
网站访问量大了后，具体的语言不是瓶颈，瓶颈都在数据库。用c，，php，java,net都能操作mysql数据库获取数据。语言之间可能存在速度执行差异，但是其实这种差别已经很小了。至少我觉得，给予用户感觉不到明显。执行相差0.0001秒用户感觉并没有明显的区别。可能说，大并发(很多用户同时访问)的时候，就会体现到差别了。其实我觉得，大并发访问是数据库瓶颈。等待数据库给予数据。没达到一定级别实在体现不了差别。数据库数据量达到一定级别。语言相差0.001s会给予用户体验上的差别。我想，这也是为什么php很适合做web开发了。解析页面速度快(解释型语言，不需要编译)。可以用java来与数据库打交道获取数据。php不直接操作数据库，而是调用java提供的数据接口，获取数据，马上展示在页面中。这是利用了php的页面执行速度快的一个优势。
备份图片数据和迁移数据方便
图片以二进制形式存储在数据库，有一个好处：备份的时候方便。直接备份数据库，图片也跟着备份。换句话说，迁移环境的时候是方便。
而图片放在磁盘上的话，数据库中存储的只是图片路径。备份数据库后。磁盘上的图片也要跟着备份才行。
不过我觉得，备份这个好处不是很明显。图片在磁盘上，备份磁盘也没很大的事情。打包压缩也可以了。互联网环境毕竟与传统的软件开发不同，web开发比较关注网站速度。也就是数据库的速度。就像互联网开发中，有时候为了速度，用空间换时间的做法比较普遍，所以往往在设计数据库的时候并不一定遵循传统数据库设计三大范式。
数据库中保存的是图片路径的话，在web开发环境下，其实有个更好处，就是cdn加速。就是下面要进行总结的地方。
二、数据库中保存图片路径
一般是这样子的：
按照年月日生成路径。具体是按照年月日还是按照年月去生成路径，根据自己需要(不一定是按照日期去生成)。
理解为什么要分散到多个文件夹中去才是关键，涉及到一个原理就明白了：
操作系统对单个目录的文件数量是有限制的。当文件数量很多的时候。从目录中获取文件的速度就会越来越慢。所以为了保持速度，才要按照固定规则去分散到多个目录中去。
图片分散到磁盘路径中去。数据库字段中保存的是类似于这样子的”images/2012/09/25/ 1343287394783.jpg”
原来上传的图片文件名称会重新命名保存，比如按照时间戳来生成，1343287394783. jpg。这样子是为了避免文件名重复，多个人往同一个目录上传图片的时候会出现。
反正用什么样的规则命名图片，只要做到图片名称的唯一性即可。
比如网站的并发访问量大，目录的生成分得月细越好。比如精确到小时，一个小时都可以是一个文件夹。同时0.001秒有两个用户同时在上传图片(因为那么就会往同一个小时文件夹里面存图片)。因为时间戳是精确到秒的。为了做到图片名称唯一性而不至于覆盖，生成可以在在时间戳后面继续加毫秒微秒等。总结的规律是，并发访问量越大。就越精确就好了。
我现在还没碰到需要这么精细的。概率比较少。
有个方面总结一下：为什么保存的磁盘路径，是”images/2012/09/25/1343287394783.jpg”，而不是” /images/2012/09/25/ 1343287394783.jpg”(最前面带有斜杠)
我的理解：
连那个斜杠都不要。这里也是做到方便以后系统扩展。
在页面中需要取出图片路径展示图片的时候，如果是相对路径，则可以使用”./”+”images/2012/09/25/1343287394783.jpg”进行组装。
如果需要单独的域名(比如做cdn加速的时候)域名，img1.xxx.com,img2.xxx.com这样的域名，
直接组装 “http//img1.xxx.com/”+”images/2012/09/25/1343287394783.jpg”
当然数据库是可以在前面加斜杠/保存起来,/images/2012/09/25/ 1343287394783.jpg
其实不方便统一。比如相对路径载入图片的时候，则是”.”+” /images/2012/09/25/ 1343287394783.jpg”
可能我还没体会到坏处，以后会遇到问题的。不过，遵循惯例不加斜杠” images/2012/09/25/ 1343287394783.jpg”就对了。
涉及到一个新问题：为什么大部分系统都不会域名保存进去，像这样子http//wwwxxx.com/images/2012/09/25/1343287394783.jpg保存到数据库中
曾经与一个上海的网友聊天，他也是习惯不会把域名保存数据库中过去。但当时我们两聊的时候，他对”域名保存进去的做法”与”不保存域名进去”也没有一个明确利弊。他就觉得，没有什么明显的区别啊。
了解的知识越多，越有利于我们做决定。可能就是一个”感觉区别不是很大”的影响下，去做一个决定，反而对后面是比较大的影响的。至少是增加自己的工作量了。
其实把域名保存进去，也不是什么滔天大罪的事情。但凡是经验丰富的开发人员都不会这样子做。这是一个经验积累出来的，所以上海那个网友也对此并没有明显的概念很正常，他说他不知道cdn方面的(当然觉得存个域名进去没什么大不了的)。需要了解cdn知识，什么情况下会用到cdn知识。
虽然是做开发人员，不需要关注运维和服务器之类的知识。不过了解一些就有利于理解了。
这里涉及到cdn加速。
关于cdn原理(就是内容分发网络)
cdn，我理解其本质就是为了解决距离远产生的速度问题，使用就近的服务。
从中国请求美国一台服务器上的图片。一般比较慢，因为距离这么远，网络传输是存在损耗的，距离越远，传输的时间就越长。一般会看到浏览器左下角显示：“已响应,正在传输数据..”。这不是服务器本身问题了。实际上服务器早就响应请求，把数据发给客户端，但是网络问题，就一直在传输，没传完了。
在中国，是南北距离远的问题。南北还会涉及到跨网，南方用户使用电信居多，北方用户网通居多。两个线路需要跨越，会有时间延迟。北京到广州的距离，如果直接请求
cdn加速就是适应这个需求产生的：现在不请求美国的服务器。直接在中国安放节点(节点是比较笼统的词语，可以理解成一台服务器，也可以理解成一个机房，就是一个点嘛)，请求距离近的节点。这样子就不需要那么远的距离了。
记得以前在长沙的网站，团购以城市分站的形式。北京和长沙用的是同一套程序。服务器在长沙。北京用户访问北京站的时候,实际上需要远距离访问长沙的服务器。速度怎么都快不起来。跟服务器性能完全没关系。当时不懂这些。不清楚怎么折腾。看那本《前端优化技巧》，想办法去做js代码压缩，浏览器缓存之类的。实际上瞎折腾。不是说这些前端优化不重要，哲学上有主次矛盾之分，瓶颈在哪里就去突破哪里。没解决主要矛盾，问题并不会迎刃而解。当时也不是数据库瓶颈。如果去优化数据库。也不会明显改善。就那点数据量。根本就达不到瓶颈。哪里谈得上主要矛盾。随着后来去其他公司工作，接触一些东西，类似不找瓶颈的优化例子发生在身边好几次了，先没找到瓶颈就瞎去优化。我的同事可能是抱着多多益善的心态去做的，但主要矛盾(技术上说是瓶颈)没找到，也没改善。
当时如果没想到是距离问题。也就不会想到cdn，当时其实我根本不知道cdn服务。我只知道，google这些网站肯定在中国部署的服务器，要不然，中国用户还去访问美国的服务器，那再好的服务器都会速度慢的。
由于自己搭建cdn环境和机房的资金比较大（需要大量的服务器），也需要人力维护。反正一般的公司弄不起，其实根本不划算。淘宝以前用商用的cdn服务，后来商用的扛不住了，就搭建了自己的cdn网。我不知道新浪有没有自己搭建，但其实我觉得跟淘宝的特点有关，店铺很多，无论是商品还是交易记录总计起来商品很多的图片，图片都是静态的部分，cdn本来就是用来做静态的(图片，css，js等)请求分发用的。
我之前在网上看到一句话，cdn网络不是一般的公司玩得起的。
一般的公司自己搭建cdn网络成本高，所以就有商业的cdn提供付费租用服务，这是一项很成熟的业务，很多这样的公司，大部分全国性的互联网公司都会使用到cdn。
总结：cdn服务。对于静态内容是非常适合的。所以像商品图片，随着访问量大了后，租用cdn服务，只需要把图片上传到他们的服务器上去。
例子：北京访问长沙服务器，距离太远。我完全可以把商品图片，放到北京的云服务（我觉得现在提供给网站使用的云存储其实就是cdn，给网站提供分流和就近访问）上去。这样子北京用户访问的时候，实际上图片就是就近获取。不需要很长距离的传输。
自己用一个域名img.xxxcom来载入图片。这个域名解析到北京的云服务上去。
做法:数据库中保存的是” images/2012/09/25/1343287394783.jpg”,
这些图片实际上不存储在web服务器上。上传到北京的cdn服务器上去。
我从数据库取出来，直接”img.xxxcom/”+” images/2012/09/25/1343287394783.jpg”
比如如果还有多个，就命名img1.xxcom、img2.xxcom
反正可以随便。所以如果把域名直接保存进去。就显得很麻烦了。迁移麻烦。
像淘宝，凡客，亚马逊这些电子商务网站，我们看到请求的时候，下面往往会有
img1.xxx.cdncom
img2.xxx.cdncom
其实他们保存在数据库中的是相对路径。有些是不需要在数据库保存的，缩略图可以实时访问的时候用程序生成(节省很多存储空间)
实际上，把域名保存在数据库中，非常不利于系统迁移。一旦换个域名的话，原来保存在数据库中的是“wwwabc.om/images/xxxxxx“,因为路径都在数据库中写死了。下回换个域名就用不了了。那个时候自己去写sql语句批量更新字段吧。
几个术语：
icp，Internet Content Provider，也就是网络内容提供者。联想到我们运营一个网站需要icp备案了吗？你自己运营网站，你就是icp服务商
IDC（Internet Data Center)，互联网数据中心。IDC的概念，目前还没有一个统一的标准。通俗点，就是提供机房托管(服务器租用和托管)，域名注册之类的。
关于淘宝的图片存储
了解到：淘宝以前使用了商用的存储。但是没法满足需求。据说，到2010年，淘宝网后端保存着286亿张图片。商用的系统系统没法满足需求的时候。他们就自己开发了一个tfs。大规模的小文件在磁盘上读取，需要磁盘磁头频繁的寻道和换道。大并发情况下和大量的操作确实很麻烦。其实借鉴了当时google公布的gfs设计论文。google有相册服务。为每个用户提供上传图片存储。
估计，google是率先实现这种小文件网络存储系统的。
有个观点比较好：对于老板们而言，往往觉得，用钱能解决的都不算问题。但问题在于，你遇到的问题，别人都没遇到过。那这个时候你就没有经验可以参考或者直接拿来使用。只有自己参考一些思路去创造技术了。
三、关于图片进行云存储(cdn加速)
曾经看过这个，这个是比较适合创业公司的。价格相对便宜
https//wwwupyun.com/
介绍提到，我们在全国各地部署了55个CDN节点，500多台服务器，电信，联通，移动和教育网的4线带宽。
其实，现在的云存储本质就是一个cdn服务商。你把静态的图片上传到他提供的服务器上去(ftp方式上传或者api形式编写程序上传)。他为你做就近节点访问。
计费方式：按照流量付费，99元购买100g。怎么算流量。每次访问文件的大小累加，比如一个1m的文件，访问一次流量就加1m。
我个人理解，对于图片的量不大的情况下，使用这种云服务，好处不是节省存储空间。你自己的服务器100g的空间可能创业型公司都没用完，不是什么存储空间不够用，然后去用云存储。以前我对cdn比较模糊，有这么点理解，或者以为是分散网站web服务器流压力，服务器分流。这些好处是有的。但是，只要理解了cdn产生的背景和解决的关键问题后，就会明白云存储关键好处在于：给用户就近节点访问，加速。
我觉得，如果不是出于这个考虑，或者达不到这样的目的。用其他方案也完全可以替代。何必使用云存储呢？就是你无非有实力做到全国多个节点去部署服务，才需要租用cdn来帮你，毕竟他们是规模产生的效益，专注于解决这个领域。
按类型分为：字符串类型、数字类型、日期类型、LOB类型、LONG RAW RAW类型、ROWID UROWID类型。
在讲叙字符串类型前，先要讲一下编码。字符串类型的数据可依编码方式分成数据库字符集（CHAR/VARCHAR2/CLOB/LONG)和国际字符集(NCHAR/NVARCHAR2/NCLOB)两种。数据库中的字符串数据都通过字符集将字符转换为数字后(二进制)，才存储到数据块中。通过不同的编码集转换，即便是相同的字符，也可能会转换成不同的二进制编码。这也是产生乱码的原因。数据库的编码格式一般是在创建数据库时指定的。当然也可以修改数据库的编码。
一 字符串类型
1.1：CHAR类型 CHAR(size [BYTE | CHAR])
CHAR类型，定长字符串，会用空格填充来达到其最大长度。非NULL的CHAR（12）总是包含12字节信息。CHAR字段最多可以存储2,000字节的信息。如果创建表时，不指定CHAR长度，则默认为1。另外你可以指定它存储字节或字符，例如 CHAR(12 BYTYE) CHAR(12 CHAR).一般来说默认是存储字节
注意：数据库的NLS_CHARACTERSET 为AL32UTF8，即一个汉字占用三到四个字节。如果NLS_CHARACTERSET为ZHS16GBK，则一个字符占用两个字节。
1.2： NCHAR类型
这是一个包含UNICODE格式数据的定长字符串。NCHAR字段最多可以存储2,000字节的信息。它的最大长度取决于国家字符集。
1.3 VARCHAR类型
不要使用VARCHAR数据类型。使用VARCHAR2数据类型。
1.4： VARCHAR2类型
变长字符串，与CHAR类型不同，它不会使用空格填充至最大长度。VARCHAR2最多可以存储4,000字节的信息。
1.5： NVARCHAR2类型
这是一个包含UNICODE格式数据的变长字符串。 NVARCHAR2最多可以存储4,000字节的信息。
二. 数字类型
2.1 NUMBER类型
NUMBER(P,S)是最常见的数字类型，可以存放数据范围为10130~10126（不包含此值)，需要1~22字节(BYTE)不等的存储空间。
P 是Precison的英文缩写，即精度缩写，表示有效数字的位数，最多不能超过38个有效数字
S是Scale的英文缩写，可以使用的范围为-84~127。Scale为正数时，表示从小数点到最低有效数字的位数，它为负数时，表示从最大有效数字到小数点的位数
下面是官方文档的示例
Actual Data Specified As Stored As
123.89 NUMBER 123.89
123.89 NUMBER(3) 124
123.89 NUMBER(6,2) 123.89
123.89 NUMBER(6,1) 123.9
123.89 NUMBER(3) 124
123.89 NUMBER(4,2) exceeds precision
123.89 NUMBER(6,-2) 100
.01234 NUMBER(4,5).01234
.00012 NUMBER(4,5) .00012
.000127 NUMBER(4,5) .00013
.0000012 NUMBER(2,7) .0000012
.00000123 NUMBER(2,7) .0000012
1.2e-4 NUMBER(2,5) 0.00012
1.2e-5 NUMBER(2,5) 0.00001
2.2 INTEGER类型
INTEGER是NUMBER的子类型，它等同于NUMBER（38,0），用来存储整数。若插入、更新的数值有小数，则会被四舍五入。
2.3 浮点数
Oracle 数据库提供了专为浮点数的两种数值数据类型：
BINARY_FLOAT
BINARY_FLOAT 是 32 位、 单精度浮点数字数据类型。可以支持至少6位精度,每个 BINARY_FLOAT 的值需要 5 个字节，包括长度字节。
BINARY_DOUBLE
BINARY_DOUBLE 是为 64 位，双精度浮点数字数据类型。每个 BINARY_DOUBLE 的值需要 9 个字节，包括长度字节。
在数字的列中，浮点数有小数精度。在 BINARY_FLOAT 或 BINARY_DOUBLE 的列中，浮点数有二进制的精度。二进制浮点数支持的特殊值无穷大和 NaN （不是数字）。
2.5 FLOAT类型
FLOAT类型也是NUMBER的子类型。
Float(n),数 n 指示位的精度，可以存储的值的数目。N 值的范围可以从 1 到 126。若要从二进制转换为十进制的精度，请将 n 乘以 0.30103。要从十进制转换为二进制的精度，请用 3.32193 乘小数精度。126 位二进制精度的最大值是大约相当于 38 位小数精度。
三. 日期类型
日期类型用于存储日期数据，但是并不是使用一般的格式（2012-08-08）直接存储到数据库的。
3.1 DATE类型
DATE是最常用的数据类型，日期数据类型存储日期和时间信息。虽然可以用字符或数字类型表示日期和时间信息，但是日期数据类型具有特殊关联的属性。为每个日期值，Oracle 存储以下信息： 世纪、 年、 月、 日期、 小时、 分钟和秒。一般占用7个字节的存储空间。
3.2 TIMESTAMP类型
这是一个7字节或12字节的定宽日期/时间数据类型。它与DATE数据类型不同，因为TIMESTAMP可以包含小数秒，带小数秒的TIMESTAMP在小数点右边最多可以保留9位
3.3 TIMESTAMP WITH TIME ZONE类型
这是TIMESTAMP类型的变种，它包含了时区偏移量的值
3.4 TIMESTAMP WITH LOCAL TIME ZONE类型
3.5 INTERVAL YEAR TO MOTH
3.6 INTERVAL DAY TO SECOND
四. LOB类型
内置的LOB数据类型包括BLOB、CLOB、NCLOB、BFILE（外部存储）的大型化和非结构化数据，如文本、图像、视屏、空间数据存储。BLOB、CLOB、NCLOB类型
4.1 CLOB 数据类型
它存储单字节和多字节字符数据。支持固定宽度和可变宽度的字符集。CLOB对象可以存储最多 (4 gigabytes-1) * (database block size) 大小的字符
4.2 NCLOB 数据类型
它存储UNICODE类型的数据，支持固定宽度和可变宽度的字符集，NCLOB对象可以存储最多(4 gigabytes-1) * (database block size)大小的文本数据。
4.3 BLOB 数据类型
它存储非结构化的二进制数据大对象，它可以被认为是没有字符集语义的比特流，一般是图像、声音、视频等文件。BLOB对象最多存储(4 gigabytes-1) * (database block size)的二进制数据。
4.4 BFILE 数据类型
二进制文件，存储在数据库外的系统文件，只读的，数据库会将该文件当二进制文件处理
五. RAW LONG RAW类型
5.1 LONG类型
它存储变长字符串，最多达2G的字符数据（2GB是指2千兆字节， 而不是2千兆字符），与VARCHAR2 或CHAR 类型一样，存储在LONG 类型中的文本要进行字符集转换。ORACLE建议开发中使用CLOB替代LONG类型。支持LONG 列只是为了保证向后兼容性。CLOB类型比LONG类型的限制要少得多。 LONG类型的限制如下：
1.一个表中只有一列可以为LONG型。(Why?有些不明白)
2.LONG列不能定义为主键或唯一约束，
3.不能建立索引
4.LONG数据不能指定正则表达式。
5.函数或存储过程不能接受LONG数据类型的参数。
6.LONG列不能出现在WHERE子句或完整性约束（除了可能会出现NULL和NOT NULL约束）
5.2 LONG RAW 类型，能存储2GB 的原始二进制数据（不用进行字符集转换的数据）
5.3 RAW类型
用于存储二进制或字符类型数据，变长二进制数据类型，这说明采用这种数据类型存储的数据不会发生字符集转换。这种类型最多可以存储2,000字节的信息
六. ROWID UROWID类型
在数据库中的每一行都有一个地址。然而，一些表行的地址不是物理或永久的，或者不是ORACLE数据库生成的。
例如，索引组织表行地址存储在索引的叶子，可以移动。
例如,外部表的ROWID（如通过网关访问DB2表）不是标准的ORACLE的rowid。
ORACLE使用通用的ROWID（UROWIDs）的存储地址的索引组织表和外表。索引组织表有逻辑urowids的，和国外表的外urowids。UROWID这两种类型的存储在ROWID伪（堆组织的表的物理行id）。
创建基于逻辑的rowid在表中的主键。逻辑的rowid不会改变，只要主键不改变。索引组织表的ROWID伪UROWID数据类型。你可以访问这个伪列，你会堆组织表的ROWID伪（即使用一个SELECT …ROWID语句）。如果你想存储的rowid索引组织表，那么你就可以定义一列的表型UROWID到列检索值的ROWID伪。