http://blog.csdn.net/weiwenhp/article/details/8093506
市场上出现某个产品往往是为了满足大家啥需求.只有在某个需求背景下才会产生相应的产品来.当然也有人说再厉害点的公司是创造一种需求出来,但实际上也要人在潜意识里有那种需求才行的,人可能在潜意识里有很多需求,只不过他自己也不确切的知道,你通过一个产品帮助他发现罢了.说到这里就忍不住想来聊点题外话了,我们经常听到这样一种说法,把公司分为三种境界.
题外话,公司和程序员等级划分
一流的企业卖的标准,二流的企业卖的是品牌,三流的企业卖的是产品.
这句话的大概意思可以这样简单的理解,是像国内很多加工工厂,没有自己的品牌产品.只为他人做嫁衣裳.最有代表性的如富士康.软件行业就是各种外包公司和做各种各样小项目的呗. 像一流企业和二流企业划分其实就没那么明显了.有自己的品牌,但是名气还不能达到业界前一两位那水平可能就算二流.像微软,Oracle,google这样的名气比较大的可能就得算一流了.还有啥英特尔之类的.不过实际上这种划分也纯属娱乐拉.人家老板只要赚钱就行,管你干嘛.像人家富士康老板赚的钱还不多啊.
另外以前还看到一个给程序员分类的文章,叫啥程序员九重天来着.有点记不清了.大概是说程序员从低到高分为菜鸟,大虾,牛人,大牛,专家,学者,大师,科学家,哲学家.觉得还挺有趣的.也是纯属娱乐下了.
很多时候我们都喜欢把啥东东都来划个三六九重,高低贵贱.其实也没必要拉,觉得还是像佛教那样,觉得众生平等,所有相皆是虚妄,一切有为法如梦幻泡影,如露亦如电,当作如是观.把人生就当作一个游戏,一场梦呗.至于工作啊,政治啊,经济啊这些啥东东也不用太那么较真了.
扯得有点远了,还是来说数据库吧.
文件系统缺陷
我们知道刚开始是没有数据库这概念的.当数据量比较少时用一个啥txt文本文件就差不多就能搞定了.但数据量稍微多一点时,而且数据保存在不同的文件中.比如啥txt,doc,excel等文件.此时要处理数据还是手动去查询更改就非常之麻烦.可能得再整个简单应用程序帮你做些事了.只给你提供一些简单的用户界面.封装背后的一些复杂操作.此时数据的组织和保存还是主要依靠操作系统的文件系统.应用程序只是简化了下用户的操作.
当数据量非常多的时候会发现应用程序加文件系统的方式会存在下面一些明显的缺陷
1.数据关联度小,查询困难
举个很简单的例子,假如有一个文本文件.里面有很多信息.你想通过指定一些条件查一些信息.如果只是指定一个关键字,用它自带的查找功能就能找到.但如果条件一多咋整?比如要条件中要符合多个关键字,而且有些条件不是关键字,比如是以数字结尾的文字.你可能想可以通过正则表达式啊.实际上如果还不是非常复杂也可以呢.但如果再复杂一点,可能正则表达式就整不出来了啊.
有时你想找到一些关联信息出来.比如你要找一个人所有相关的信息.咋整?在一个个文件中
你没法知道哪些信息与另外信息有啥关联啊.
2.并发操作时容易带来混乱
我们知道现在很多数据不会是你一个人去操作.有很多人同时操作的.所以你去修改,别人也去修改很容易得到一个谁也不确定的错误结果了.
3.安全性问题
首先是文件系统中,数据都放一堆了.你没法精细的控件哪一部分数据不能被随便读取或修改.而有些重要或保密的数据必须得严格控件.另外一个就是意外出现时,比如突然断电或死机了.数据肯定会丢失.虽然你可能之前会有一些备份.但你不可能实现实时备份,所以总会丢一部分数据.而且可能断电的那瞬间.有些中间结果已经写进去了.于是系统中就有了错误的数据存在.你以后操作可能由这错误的数据带来更多的问题.
4.数据冗余与不一致性
各种各样的文件由于由不同的人操作,相与之间关联系也不大.可能一些信息在某个文件中保存了,在另外的文件中又保存了.有时修改一个文件中的信息时,另一文件中相同的信息没有同时更新.
上面说的这几个是比较容易想到的问题.可能还存在其他一些问题.
数据库怎么解决文件系统缺陷
于是为了解决上面问题,数据库应运而生.刚开始可能有啥网状结构之类的数据库.现在的话占主流的就是像Oracle,SQL Server,DB2,Sybase,MySql,PostgreSQL等一些关系型数据库.就以关系型数据库来举例说下怎么解决上面的一些问题的.
1.解决冗余不一致
在数据库里面以有为单位来组织数据.在设计表的时候你遵守一些范式就可以消除绝大部分容信息,因为你可以方便的把一些公用数据保存在一个表中,然后啥主键外键可以很方便的关联起来.
不一致性是由冗余引起的.冗余少了不一致性自然也少了.
另外你还可以通过编写啥触发器,进一步控制不一致的问题.比如你修改某一处内容时,还可以是相关的信息同时更新.这里的相关信息不一定是完全相同的信息,而只是相关.
2.解决数据查询困难,关联度小,并发操作
在表中查询数据再方便不过了啊.直接几个简单的sql,再复杂的条件用几个嵌套的sql或在where后面指定些啥条件就能整出来.而且sql语句里面也能用正则表达式.所以你更能方便的操纵数据了.并发操作嘛就用加锁来解决.
3.解决安全问题
通过各种备份手段,日记文件啥的.可以保证数据不丢.通过各种权限措施可以精细的控制你对各种数据的操作.还有啥审计功能,比如oracle,sql server中的trace啊,可以记录下来数据库中的所有操作.
数据库ACID的原理
实际上多部分时候我们用户使用数据时最为关心的一是准确,二是安全.三是速度快点.其他啥的不管你系统咋整我可不管啊.比如举个例子.你把钱存银行里去了后.你最关心的一个是钱在银行系统里数量可不能出错.比如你做一些操作时,比如存钱,取钱之后.数据一定不能错.不能突然就让你的钱变少了.当然要是变多了你可能还不会生气.这就是数据的准确性.另外一个是安全性,你的账号密码可不能被人偷了,别人把你的钱给取了啊.
为了实现安全性上面说了.这里再说下准确性.关系型数据库通常把各种操作当成一个个的事务来看待.而通过让事务具有ACID四个特性来达到准确和安全的目的.
ACID是原子性(Atomicity),一致性(Consistency),隔离性或独立性(Isolation),持久性(Durability)这四个词的简称.
下面简单介绍下四个词
原子性
我们学化学时知道刚开始人们认为原子是组成世界万物的最小粒子.是最基本的单位不能划分.实际上后面发现还有更小的一些粒子,比如啥质子,电子,侉子之类的.这里我能只取原子最初的意思,最基本的单位.那我们在数据库的操作中,也把某一组操作看成一组基本单位,比如你寄钱,然后更新自己账户,另一个人收钱,然后更新自己账户.完全完成了之后再最终提交.提示成功了.如果中间哪出问题了就回退在最初状态,把中间所有步骤撤销.
数据库虽然有了对原子事物这样的支持.但具体怎么指定一系列操作是一个原子性的事物是由具体的应用程序决定的.所以如果你应用程序中一系列操作较复杂,你也把它当原子事物来处理.假如里面还涉及到了drop表.到时那表都给删没了,你到时还咋回退去啊.
一致性.
一致性就是一个地方的某个数据改了,与之相关的信息都得更新.保持一致嘛.数据库通过主外键,约束条件,触发器这些机制基本上能实现一致性.
隔离性
并发操作时涉及到一些问题,比如你在更新某个数据时你不希望别人也同时更新.于是你要把数据先暂时隔离起来.一般用加锁来解决.你操作的时候别人就没法操作那数据了.
持久性
简单点的讲就是数据永不丢失了.一般通过实时联机备份,日志文件之类的.保证数据不丢.
关系数据库的一些缺点
世界上没有完美的事务.啥都有会缺点的.像关系型数据库也有一些缺点,这里讲一个最容易想到的缺点.就是性能问题.如果有海量的数据的话,速度会变得很慢.为啥呢,一个是你把数据都放表里,假如表里面有个几十G的内容.你查找起来能不慢吗,特别是多个表一关联查找,更加慢得死.而且你还有啥触发器,约束等一些额外的操作作用在表上.需要些额外的操作就变得更慢了.实际上你就算简单的执行一些啥操作.关系型数据库为了实现一致性,隔离性等一些目的.还会在后台做很多操作.这样得到一个结果会很慢的.
NoSQL数据库
随着现在上网的人一多,出现了很多啥sns系统,可能一看到sns这词你觉得还有点陌生,不知道啥意思.没准你眼一花还以为我说的是关于sm的网站呢.你可能对sm还是蛮熟悉的.
sns是Social Networking Sevices,这就是我们讲的社交网络,比如啥Facebook, 人人网之类的.这样的的网站数据量极大.而且不像一些商务网站那样对数据的准确性,实时性要求那么高. 但对速度要求非常高.如果你网站慢得像蜗牛了谁还能用你的.而一些商务型的系统可能得到一些复杂的结果需要等蛮长时间.比如一个查询海量复杂数据的几百行甚至上千行的SQL一执行起来可能得几个小时甚至一整天.
于是出现了很多非关系型数据库,一般叫NoSQL数据库(Not Only SQL)的简称.这些数据库不像关系型数据库都整成一个个的表.它们组织数据的结构比较灵活点.像比较出名的有MongoDB(貌似百度,淘宝,盛大,新浪都有用到它呢).还有啥Big Table, google有用它.
这些数据库可能把主要精力放在怎么提高你读写的速度上了. 而实时性准确性,安全可能不如关系型数据库吧.(这里说的实时性不是说查询速度快,而是说你更新实时,你一修改马上就给更新,相关的数据也一起更新),凡事有利有弊呗