数据库范式是什么意思—数据库范式的定义 收藏 0

到底是在讲什么“范式”

今天开会，一直听大家在讲“范式”，听了很长时间才搞明白，原来大家讲的“范式”大都不一样，至于每一种“范式”讲的是什么，到底也没有搞明白。所以，我更愿意认为，第一个人提出来“范式”这个名词，然后大家觉得不错，就跟随着也讲这个名词，但大家讲的不过都是自己理解的意思，而最初的那个概念范畴，却并不清楚。

这其中很大概率上，是大家顺从意识的体现，不管第一个人是权威人士，还是普通人，其实这样的现象一直存在。所以，不想就大家顺从权威的丑陋人格说三道四，都是工作中大家的个人选择而已，没什么必要。我反而想搞明白“范式”到底都在讲什么。

我有自己的“范式”概念理解，主要是从自己最熟悉的基础学科《数据库理论》中，所描述的范式内容获得的经验。这是一个非常严谨的原则定义和具体的分类，每一种范式都极其清晰地定义了规范，也说清楚了范式所包含的范畴。这些“范式”，是产品设计的前提，而非人们在发展过程中总结的经验和结论。

当然，不能排除这也存在经验和结论的后知后觉，否则怎么可能会讲范畴定义的这么清楚，规范和原则如此的准确，能够成为产品研发设计的参考。只是，范式的概念在定义之后，就几乎不再改变，成为大家共识的规范。所以，范式并不是发展变化的概念，反而是一种惰性的存在，让大家遵循的规范。

而大家在讲的范式是什么呢？应该说大部分都是经验和结论，大部分都是一种实践过程中运行的模式，这种模式仍然在变化中前进，并且这样的模式是模糊的，还没有被证实和证明其有效性，更不存在可复制的模具。也就意味着，大家其实是在进行经验的交流，以及结果的展示，还不能上升到模式，也就离“范式”差远了。

甚至，很多人所讲的内容，只是一种设想，相当于构建在大脑中的立体建筑，既没有实在的结果，也没有经验，这就更离谱了。连模式都不能算，只是自己的设想，或者大脑中形成的图式，而非真实可靠的东西。那么，大家讨论的时候，就是大家不同想象之间的交流，更不可能算得上“范式”了。

设想的讨论，其实是非常无聊的事情，相当于大家各自在大脑中画一幅画，除了自己谁都看不到，然后大家将各自大脑中的部分细节，拿出来开始讨论，这是认知、思想、经验等等各方面综合性的争论，本来没有所谓的正确与否，但却让大家忙的不亦乐乎、吵得不亦乐乎，很可能还会整出来一个四不像的图式来。然而，这样的讨论最常见，这样的讨论最没有意义，也不会有什么经验和总结。所以，人们常常说这是头脑风暴，只是并不需要在正式的时候，做这样的非正式的讨论。

经验的讨论，其实也非常无聊，主要是经验是不可复制的事情，只能作为参考输入，而不能看做事实根据。从小耳熟能详的寓言故事《小马过河》，其中就是这样的经验讨论，个体的认知、思想、个体状态、外部环境等等差异，都不可能让大家获得相同的经验，最后经验讨论最多看做是交流，一种输入型的参考。然而，人们很容易听他人的经验，尤其是成功经验，这是错将经验交流当成了模式复制。

模式的讨论，尚且需要确定下来基础条件、实践路径、成功经验，最关键的是可以复制。所以，商业上经常会讲模式这个课题，因为创业者先驱们已经证实了很多错误的路径、错误的方法、以及错误的成果，后来者可以尽可能规避这些错误，而从中汲取模式所带来的价值。当然，成功的模式并不常见，哪怕照着现成的模式，都不一定能够成功，所以也就不能称之为模式了。

然而，范式的讨论，却是非常严谨的过程，是共同达成的共识原则和规范，是为后来者确定好成功的模式，而非只是规避错误的手段。范式讲求严谨、清晰，并且能够统一行业领域自身发展所需的基础逻辑。就像是《数据库原理》定义的范式理论，统一了数据库产品的发展规范一样，但凡符合范式理论，大概率都不会有问题。所以，我可以很负责任的讲，其实我们开会讨论的，哪有什么范式，至少所从事的行业领域就不答应。

开会两个多小时，大家讲的内容并不深奥，甚至很多都是简单易懂的内容，不需要过分思考就可以获得，说是经验都觉得差那么点意思，只能是更多的信息展示，然后基于信息展示进行主客观情况的讨论而已。然而，人们却非要将此抽象为“范式”，这就是夸大其词了。

这种夸大，其实是很容易理解的。不夸大、抽象出非常有吸引力、价值感的名词，似乎做的事情就非常低级，就像是开会的大部分人想当然地认为底层操作型的人是低级工作一样，天然就带着一种评价的眼光，并且是向上仰视的方式生存。所以，工作中不得不抽象，不得不夸大，也不得不去定义那些名词。只是，听者们的语言水平也并不怎样，不见得听得明白到底在讲什么，到底说的又是什么。

我猜测，在一段时间里，“范式”这个词会在参会者身上，在参会者的团队、合作伙伴的口中，不断地出现，不断的蒙人，让人听得云雾缭绕的感觉。人们很难一下子跳出来，因为自己也不明白到底是在讲什么，但是听着特别高端，所以就一直误传下去。除非哪一天，有一个权威人士提出来：“不要再讲范式了”，说不定才能止息这场传播。

明明白白讲清楚其实就很不容易，让人们听懂讲的内容才是演讲者最重要的事情，如今却非要让人们学着讲这些虚伪的、言过其实的内容，还动不动讲出这么高雅的词汇，将大家讲的云雾缭绕，这无论如何也不能称之为成功的演讲。然而，从大家开始不断引用“范式”，不断解释自己或是设想、或是经验、或是模式，但绝对不是范式的内容来看，听不听得明白是另一回事，大家获得了这个新的名词更重要。

回归朴实的言行举止，确实很难。我们几乎抵不住诱惑，抵不住向上仰视的眼神，更抵不住自尊，最后开始妥协，开始虚头巴脑，开始云里雾里，讲明白与否已经不再重要，关键还是让大家觉得高雅，却找不回了朴实的模样。

开会的时候，刚开始还会绞尽脑汁想要搞明白每一个细节，每一句重点内容，很快就向这些云里雾里的内容双手投降，不经意间开始数到底全场出现了多少次“范式”，多少人使用“范式”这个名词，真是“莫大的收获”。

我很自觉地忍住了，没有说一句话，除了专心在数之外，还在思考我应该如何朴实的言行举止。

工具：文心一格

描述：范式。

点击关注，持续更新；

或者微信公众号搜索：TickTockLogs。

数据库三大范式

我们为了减少数据库中冗余，避免操作异常，造成数据库的浪费和报错，这时我们在设计数据库时就要按照一定的规则来避免这种以上这种情况，这种规则叫做范式。范式简单来说就是设计数据库的一些规范。

1-满足这些规则的数据库，在呈现上会显得更加的简洁和结构条理清晰。

2-在插入（insert），删除（delete），更新（update）操作时不会发生异常。

3-如果不满足这些规则时，每人都有不同的显现方式会在数据库的形式上会显得乱七八糟，结构混乱，给数据库的编程人员造成很大的麻烦，可能储存了大量的冗余信息。

第一范式（1NF）

定义：数据库表中的字段都是单一属性

——字段不可再分（列唯一）

——同一个列中不能有多个值（值唯一）

这些单一属性由基本类型构成，包括：整数，实数，字符型，逻辑型，日期型和其他类型

第二范式（2NF）

定义：在满足第一范式的前提下，数据库中的每张表均有主键。

1-单字段主键

2-联合主键（由两个或者两个以上的字段共同组成的主键）：不能存在联合主键中某个主键字段决定非主键字段的情况

该表不满足第二范式，因为客户和开户银行为联合主键，客户决定客户电话，开户银行决定开户行地址，违反了联合主键字段决定非主键字段，做法就是将该表拆分为客户表和银行表即可。

第三范式（3NF）

定义：在满足第二范式的前提下，数据表的主键字段不存在传递依赖关系。即：非主键字段不能决定其他的非主键字段。

该表“工号”为主键，“部门”决定“部门电话”，“部门”决定“部门主管”，则存在非主键字段决定其它的非主键字段，不符合第三范式。符合范式，做法将其拆分为员工表和部门表。

本文作者及来源:Renderbus瑞云渲染农场https://www.renderbus.com