我对CRUD的一些认识

CRUD,一个后端程序员应当知道的组合，对应着数据库的四种基本操作：增删改查。(这个顺序,在数据的生命周期(后面会提到)是不对的，应当是查=>增=>改=>删)

CRUD四个字母看起来简单，用起来就很复杂，就像我们学生时代所学的数学。

已知：1+1 = 2，求证，2cos(0) = 圆周率；

CRUD在SQL语法中CRUD的运算和数学中集合的运算很相似（也许就是从数学中来的吧，因为电脑也叫做计算机嘛！）

对于CRUD每一个的单独子运算是SQL是有语法的，比如WHERE子句以及聚合函数等。

但是对于一个整体的【操作】的运算却不是那么明显，或者说是给我们提供一个比较快捷（懒惰）的语法。

对于CRUD哥四个(后面可能会提到”哥四个“表示的都是CRUD)来说，他们对数据表的【多操作运动】并不能理解为同步进行，至少说在我们自己实现更为复杂的数据表有关的业务逻辑（比如同步，在下面会提到）时，其执行过程必须是同步的。

首先我们对CRUD进行分类，按照不同标准我们可以划分为以下几种组合。

【1】、对【数据】的操作方式——静态操作:与数据的生命周期无关的操作，可以独立于数据表之外。动态操作:与数据的生命周期完全相关的操作，依赖于数据表。数据绝对生命周期:增加====>删除。

　　静态:查

　　动态:增、删、改

【2】、对【数据表】的操作方式——数据在数据表中【量】的变化，而【1】所进行的分类也可以说是对数据【质】的变化的分类

　　增加:增

　　不变:查，改

　　减少:删

【3】、对于【紧前事件】的依赖——哥四个对于【多操作运动】中的盟约。充分不必要:当前操作对于下一个操作来说【有没有都可以】，有了就更好（非资源消耗层面），充分必要条件，如果当前操作没有进行完，可能会对下一个操作产生【致命的】后果。从这个分类的意义上来讲，操作的顺序应当为:查=>增=>改=>删。因此这种分类方式，也可以称之为：以数据【生命周期】的分类。

　　充分不必要:

　　　next:now

　　　　增:改，删。

　　　　删:查，增。

　　　　改:删，查。

　　　　查:无。

　　充分必要:　

　　　next:now

　　　　增:查。====>查询重复主键。

　　　　删:改。====>修改删除条件。

　　　　改:增。====>增加条件数据。

　　　　查:增，改，删,====>查询数据被添加，查询数据被修改，查询数据被删除。

那么，我们对操作进行分类有什么作用呢？用途是相当大的。

　　1、对于【1】的分类方式，学过数据结构和算法的知道，某些结构的容器对静态或动态两种不同的操作方式有着不同的优势，比如列表在静态操作上要好于链表，而链表在动态操作要好于列表。在前台方面，将两种操作对应的请求方式分离会大幅度降低大数据流的成本。

　　2、对于【2】的分类方式，是比【1】站在了更高的一个角度，这种分类在业务的方向上，会更偏向于整合优秀的持久层开发框架，从而以比较低的IO成本做到高效操作数据库。在前台方面也是如此，只不过前台是节省DOM渲染的成本。

　　3、对于【3】的分类方式，应当是每一个后端程序员在自己的编程生涯中摸索出来，存在于经验当中但尚未上升到理论层面的一些东西。在数据的生命周期中:查，增，改，删。如果任何一步缺位，越位，错位整个业务必定会出现bug。因此这种分类方式的应用方向也就是站在了比【2】更高的一个角度，即面向业务的框架。不同于面向代码的一般框架，这种框架负责完全托管整个业务周期，包括从持久层到业务层到表现层，以及逆向的业务周期。

　　似乎上面对于CRUD分类意义的方法都是在为框架的存在而寻找原因，本人要澄清的是，这种描述不等同于我个人对以框架为开发模式的完全认同，因为我的认识是:框架模式的使用意味着业务逻辑在某些方面的灵活性丧失，从而整个服务慢慢发展出一种专门化的特点，专门化也许与公司的发展战略相匹配，这绝对是很好的，但对于综合发展战略或灵活发展战略以及面向需求的发展战略，就显得有些力不从心。

　　我们基于【3】的分类方式对CRUD的更多关系进行梳理。