自己原文公众号： https://mp.weixin.qq.com/s/lZo9kgkjEY5qyUuRB0Z6rQ
当今开发语言用的最多的是什么？（PHP是最好的语言）java和Python等等还没说话。其实这些都是开发语言。我记得我有一次培训，问在座的不连接数据库的请举手。几乎都举手了。说明脱离数据库的开发几乎不存在。几乎不是说100%。前端就不需要连接数据库。
如果说连接数据库那么其实就不管你是VC++还是java或者Python。数据库统统不认，数据库提供的是ODBC、JDBC等等封装好的东西，你只管用就行。所以说码农才有了这种，就是做增删改查。而做这几个动作只能通过SQL（因为通过其他的数据库不认）。这里要说的redis 的put、mongo的insert、hbase的put、neo4j的match这些也是他们自己的SQL（虽然不是结构化查询语言了，因为是半结构化数据，不能叫S了，但是这里主要是表达一个意思）
1970年，在加利福尼亚IBM的圣约瑟研究实验室工作的年轻程序员codd，提出了根据不同数据之间的能够辨别的关系来组织数据的概念。数据将被组织在二维表（行和列）中，一个表中的特殊项目可以与另一个表中的数据产生关系。codd看到了需要减少或除去数据中的冗余，并且要允许数据通过逻辑而不是物理辨别来进行存取。codd关键的想法是通过适当数据的表对数据加以组织，也就是标准化的处理过程。
下面是引用：
1974年E.F.codd提出了全关系系统的十二条基本准则，只有遵循这些准则的系统才是全关系系统。以此可作为评价或购买关系产品的标准。
准则0：一个RDBMS必须能完全通过自身的关系能力来管理数据库。这意味着，一个自称为关系型的DBMS必须能在关系这个级别支持数据库的插入、修改和删除。准则0是下面十二条准则的基础。不满足准则0的DBMS都不是RDBMS。
准则1：信息准则。RDBMS的所有信息都应在逻辑一级用同一个方法----表（Table）中的值显示出来。而且，每个表的表名，表中的列名和域名等，都是用系统内的数据字典表中的值表示的。数据字典本身是一个描述元数据的关系数据库。
准则2：保证访问原则。依靠表名、主码和列名的组合，应保证能够访问关系数据库中的每个数据项值。保证访问原则规定，关系系统不能采用面向机器的寻址法，而必须采用关系系统独有的关联寻址的访问模式.
准则3：空值的系统化处理。空值是"不知道"或"无意义"的值，它不是一个具体的值（如零、空字符串等）。空值的概念很重要，在全关系DBMS中支持空值，就是要用一个系统化的方式处理空值。
准则4：基于关系模型的动态联机数据字典。数据库的描述在逻辑级上应和一般数据采用相同的表示方法，使得授权用户能使用查询一般数据所用的关系语言来查询数据库的描述信息。本准则不仅使每个用户只需学习一种数据模型，而且授权用户还可方便地扩充字典，使之变成完备、主动的关系数据字典。
准则5：统一的数据子语言准则。一个关系系统可以有几种语言和多种终端使用方法。但必须有一种语言，该语言的语句可以表示为具有严格语法规则的字符串，并能全面地支持以下定义：数据定义、视图定义、数据操作（交互式或程序式）、完整性约束、授权、事务处理功能（事务的开始、提交和退回）。关系方法是高度动态的，处于频繁的运行处理之中。因此，没有必要把说明的功能分为若干种语言来实现。关系数据库是一体化的数据子语言，它使程序员可首先交互地调试数据库语言，调试正确后再嵌入程序中，从而可大大提高程序员的生产效率。
准则6：视图更新准则。所有理论上可更新的视图也应该允许由系统相同更新。"一个视图在理论上是可更新的"指的是，存在一个与时间无关的算法，该算法可无二义性地把对此视图的更新要求转换为对基本表的更新序列。
准则7：高级的插入、修改和删除操作。把一个基本关系或导出关系作为单一的操作对象处理。这不仅适合于数据检索，而且适合于数据的插入和删除。以关系为操作对象不仅简化了用户查询，也为系统进行查询优化提供了很大的余地。该准则对于获得有效的分布式事务处理也是十分重要的，可避免从远程结点传送一条记录就要发出一次请求，实现一次请求传送一个关系，从而节省通信代价。
准则8：数据的物理独立性。无论数据库的数据在存储表示或存取方法上作何变化，应用程序和终端活动都保持逻辑上的不变性。
准则9：数据的逻辑独立性。当对基本关系进行理论上信息不受损害的任何变化时，应用程序和终端活动都保持逻辑上的不变性。
准则10：数据完整的独立性。关系数据库的完整性约束条件必须是用数据子语言定义并存储在数据字典中，而不是在应用程序中定义。除了实体完整性和参照完整性外，具体的关系数据库还可能有反映业务政策和管理规章的完整性约束条件。这些完整性条件都应该能用高级的数据子语言定义，并能存入数据字典，从而，当约束条件变化时，只需改变数据字典中定义的完整性语句，而不会逻辑上影响应用程序和终端活动。
准则11：分布独立性。对于如下两类具体问题：其一，原来的DBMS只管理非分布式数据，现在要引入了分布式数据；其二，原来的DBMS能管理分布式数据，现在要改变原来的数据分布。在这两种情况下，由于RDBMS具有特定的数据子语言，都能使应用程序和终端活动保持逻辑不变性。
准则12：无破坏准则。如果一个关系系统具有一个低级（一次一个记录）语言，该语言不能破坏或绕过完整性准则和用高级关系语言表达的约束条件。以上这十二条准则都以准则0为基础，但仅有准则0是不够的。
目前，虽然还没有一个DBMS产品是全关系型的，但随着人们对数据库技术研究的进一步深入，加上软件运行环境的改变，相信以后一定会出现越来越好的全关系型的DBMS，以满足人们各类应用场合对数据库产品的需求。
1974年，IBM的Don Chamberlin和Ray Boyce将Codd关系数据库的12条准则的数学定义以简单的关键字语法表现出来，里程碑式地提出了SQL（Structured Query Language）语言
引用完毕。
可以看出是SQL是用简洁的语言完成了底层物理数据的映射。数据库是和操作系统打交道的，甚至和硬件打交道CPU、内存和磁盘。我们日常经常看到的一个SQL居然会把数据库拖死，其实就是因为SQL写的不好，把服务器的所有资源全部调动起来，导致资源耗尽了。是数据库的问题吗？是SQL的问题吗？绝对是用的人的问题。
今天看到一篇文章《数据库奔溃的时候，没有一个慢SQL是无辜的》如果使用者不在乎奔溃，那么这能怪谁呢？
数据库没人用，不会出问题。用的好也不会出问题。大家可以看看微信、支付宝、百度、谷歌等等很少、几乎不出问题。数据量不大吗？不是而是大家都能遵守最起码的开发规范，正确使用SQL。而不是肆无忌惮的使用，比如给redis来一个keys *，也一样出事。
所以如果不是硬件损坏、（数据库我一向反对使用虚拟机、容器）不是虚拟化问题。那么数据库上发生的性能问题几乎全是使用不当造成的。
按照规范使用，即安全生产，那么我们也几乎不太可能出现问题。这个规范对于大的互联网公司来说不是问题，因为这是基本素质。如果违反怎么办？按照规章制度处罚。三大纪律八项注意如果对违反的没有处理，那么军队怎么得到拥护呢？
《史记·高祖本纪》：“与父老约，法三章耳；杀人者死，伤人及盗抵罪。余悉除去秦法。
