1. 三大范式首先要明白”范式（NF）”是什么意思。按照教材中的定义，范式是“符合某一种级别的关系模式的集合，表示一个关系内部各属性之间的联系的合理化程度”。数据库范式也分为1NF，2NF，3NF，BCNF，4NF，5NF。一般在我们设计关系型数据库的时候，最多考虑到BCNF就够。符合高一级范式的设计，必定符合低一级范式，例如符合2NF的关系模式，必定符合1NF。
1.1 第一范式消除一个字段包含多个数据库值，消除一个记录包含重复的组（单独的一列包含多个项目），即可满足1NF。符合1NF的关系中的每个属性都不可再分。如下表所示的情况，就不符合1NF的要求。
实际上，1NF是所有关系型数据库的最基本要求，你在关系型数据库管理系统（RDBMS），例如SQL Server，Oracle，MySQL中创建数据表的时候，如果数据表的设计不符合这个最基本的要求，那么操作一定是不能成功的。也就是说，只要在RDBMS中已经存在的数据表，一定是符合1NF的。 但是仅仅符合1NF的设计，仍然会存在数据冗余过大，插入异常，删除异常，修改异常的问题，例如对于表中的设计：
（1）每一名学生的学号、姓名、系名、系主任这些数据重复多次。每个系与对应的系主任的数据也重复多次——数据冗余过大 假如学校新建了一个系，但是暂时还没有招收任何学生（比如3月份就新建了，但要等到8月份才招生），那么是无法将系名与系主任的数据单独地添加到数据表中去的——插入异常。 （2）假如将某个系中所有学生相关的记录都删除，那么所有系与系主任的数据也就随之消失了（一个系所有学生都没有了，并不表示这个系就没有了）。——删除异常 （3）假如李小明转系到法律系，那么为了保证数据库中数据的一致性，需要修改三条记录中系与系主任的数据。——修改异常。 （4）正因为仅符合1NF的数据库设计存在着这样那样的问题，我们需要提高设计标准，去掉导致上述四种问题的因素，使其符合更高一级的范式（2NF），这就是所谓的“规范化”。
1.2 第二范式消除部分依赖性即可转化为2NF。部分依赖性表示一个记录中包括的字段只依赖于主键的一部分。解决部分依赖性的最简单方法是将复合主键分成两部分，每一部分表示一个单独的表。其改进是，2NF在1NF的基础之上，消除了非主属性对于码的部分函数依赖。接下来对这句话中涉及到的四个概念——“函数依赖”、“码”、“非主属性”、与“部分函数依赖”进行一下解释。
1.2.1 函数依赖我们可以这么理解（但并不是特别严格的定义）：若在一张表中，在属性（或属性组）X的值确定的情况下，必定能确定属性Y的值，那么就可以说Y函数依赖于X，写作 X → Y。也就是说，在数据表中，不存在任意两条记录，它们在X属性（或属性组）上的值相同，而在Y属性上的值不同。这也就是“函数依赖”名字的由来，类似于函数关系 y = f(x)，在x的值确定的情况下，y的值一定是确定的。 例如，对于上例表中的数据，找不到任何一条记录，它们的学号相同而对应的姓名不同。所以我们可以说姓名函数依赖于学号，写作 学号 → 姓名。但是反过来，因为可能出现同名的学生，所以有可能不同的两条学生记录，它们在姓名上的值相同，但对应的学号不同，所以我们不能说学号函数依赖于姓名。表中其他的函数依赖关系还有如：系名 → 系主任 学号 → 系主任 （学号，课名） → 分数 但以下函数依赖关系则不成立：学号 → 课名 学号 → 分数 课名 → 系主任 （学号，课名） → 姓名。
1.2.2 码设 K 为某表中的一个属性或属性组，若除 K 之外的所有属性都完全函数依赖于 K（这个“完全”不要漏了），那么我们称 K 为候选码，简称为码。在实际中我们通常可以理解为：假如当 K 确定的情况下，该表除 K 之外的所有属性的值也就随之确定，那么 K 就是码。一张表中可以有超过一个码。（实际应用中为了方便，通常选择其中的一个码作为主码）
1.2.3 非主属性包含在任何一个码中的属性成为主属性。
1.3 第三范式消除可传递依赖性即可满足3NF。可传递依赖性表示记录中至少一个值不依赖主键，而是依赖于这个记录中的另一个字段。 符合3NF要求的数据库设计，基本上解决了数据冗余过大，插入异常，修改异常，删除异常的问题。当然，在实际中，往往为了性能上或者应对扩展的需要，经常 做到2NF或者1NF，但是作为数据库设计人员，至少应该知道，3NF的要求是怎样的。
1.4 BCNF范式要了解 BCNF 范式，那么先看这样一个问题：
如下：某公司有若干个仓库；每个仓库只能有一名管理员，一名管理员只能在一个仓库中工作；一个仓库中可以存放多种物品，一种物品也可以存放在不同的仓库中。每种物品在每个仓库中都有对应的数量。那么关系模式 仓库（仓库名，管理员，物品名，数量） 属于哪一级范式？答：已知函数依赖集：仓库名 → 管理员，管理员 → 仓库名，（仓库名，物品名）→ 数量码：（管理员，物品名），（仓库名，物品名）主属性：仓库名、管理员、物品名， 非主属性：数量，不存在非主属性对码的部分函数依赖和传递函数依赖。此关系模式属于3NF。基于此关系模式的关系（具体的数据）可能如图所示：
好，既然此关系模式已经属于了 3NF，那么这个关系模式是否存在问题呢？我们来看以下几种操作：先新增加一个仓库，但尚未存放任何物品，是否可以为该仓库指派管理员？——不可以，因为物品名也是主属性，根据实体完整性的要求，主属性不能为空。某仓库被清空后，需要删除所有与这个仓库相关的物品存放记录，会带来什么问题？——仓库本身与管理员的信息也被随之删除了。如果某仓库更换了管理员，会带来什么问题？——这个仓库有几条物品存放记录，就要修改多少次管理员信息。 从这里我们可以得出结论，在某些特殊情况下，即使关系模式符合 3NF 的要求，仍然存在着插入异常，修改异常与删除异常的问题，仍然不是 ”好“ 的设计。造成此问题的原因：存在着主属性对于码的部分函数依赖与传递函数依赖。（在此例中就是存在主属性【仓库名】对于码【（管理员，物品名）】的部分函数依赖。解决办法就是要在 3NF 的基础上消除主属性对于码的部分与传递函数依赖。仓库（仓库名，管理员）库存（仓库名，物品名，数量）这样，之前的插入异常，修改异常与删除异常的问题就被解决了。以上就是关于 BCNF 的解释。 BCNF（Boyce-Codd Normal Form）可以看作更好的3NF。在满足第二第三范式的情况下，决定项内部也不能部分或传递依赖。简单点看就是：箭头左边的必须是码，不是码的就不是BCNF。
2. 数据库设计相关2.1 数据规范化关系模式满足的约束条件称为范式。范式由低到高分为：1NF、2NF、3NF、BCNF、4NF、5NF。 规范化：就是指把一个低一级的关系模式分解为高一级关系模式的过程。 规范化的基本思想：逐步消除不合适的函数依赖，使数据库中的各个关系模式达到某种程度的分离。 函数依赖：通俗的说，就像自变量x确定之后，相应的函数值f(x)也就唯一的确定了一样。 码：给定一个码能完全决定一个元组。一个关系可能有多个码，选其中一个做为主码。包含在任一码中的属性称为主属性。不包含在任何码中的属性称为非主属性。 第一范式（1NF）：如果关系中所有属性的值域都是简单域，其元素（属性）不可再分，是属性项不是属性组，那么关系模式属于第一范式。这一限制是关系的基本性质，所以任何关系都必须满足第一范式。 第二范式（2NF）：如果一个范式属于1NF，且所有的非主属性都完全的依赖主属性，称为第二范式。可以用分解的方法消除部分依赖的情况，而使关系达到2NF的标准。方法是从现有关系中分解出新的关系表，使每个表中所有的非关键字都完全依赖于各自的主关键字。 (消除部分依赖) 第三范式（3NF）：如果一个关系属于2NF，且每个非主属性不传递依赖于主属性，这种关系是3NF。从2NF中消除传递依赖，就是3NF。 (消除部分传递依赖) BC范式（BCNF）：无论2NF还是3NF都没有涉及主属性间的函数依赖，所以有时仍会引起一些问题。 定义：如果关系模式属于1NF，且每一个函数依赖关系中的决定因素都包含码，则关系满足BC范式。主属性对不含他的码完全函数依赖，没有属性完全函数依赖于一组非主属性。 多值依赖和4NF：第四范式是BC范式的推广。 定义：关系模式R
2.2 数据库设计2.2.1 常用方法：(1)基于3NF的数据库设计方法： 在需求分析的基础上，识别并确认数据库模式中的全部属性和属性间的依赖，将他们组织成一个单一的关系模式，然后再分析模式中不符合3NF的约束条件，用投影和连接的办法将其分解，使其达到3NF。 (2)LRA方法：逻辑记录存取法。 (3)基于实体联系（E-R）的数据库设计方法。 (4)基于视图概念的数据库设计方法。 (5)面向对象的关系数据库设计方法。 通常将数据库设计分为需求分析、概念结构设计、逻辑结构设计和数据库物理设计4个阶段。
2.2.2 概念结构设计概念结构设计常用的方法是实体分析法、属性综合法。 二元联系的类型与定义：二元联系指两个实体之间的联系。分为一对一、一对多、多对多3种。 （1）一对一联系：对于实体集A中的每一个实体，实体集B中至多有一个实体与之联系。 （2）一对多联系：对于实体集A中的每一个实体，实体集B有n个实体（n>=0）与之联系，反之对于实体集B中的每一个实体，实体集A至多只有一个实体与之联系。则实体集A与实体集B有一对多关系，记为1:n。 （3）多对多联系：若对于实体集A中的每一个实体，实体集B有n个实体（n>=0）与之联系。反过来，对于实体集B中的每一个实体，实体集A有m个实体（m>=0）与之联系。则实体集A与实体集B具有多对多联系，记为m:n。 消除冗余联系：若出现两个或两个以上的联系表示的是同一概念，则存在着冗余的联系，具有冗余联系的E-R模型转换为关系模型可能会得到非规范化的关系，因此必须予以消除。 警惕连接陷阱： 连接陷阱是一种存在语义缺陷的联系结构，分为扇形陷阱、断层陷阱、深层扇形陷阱3种信息。 扇形陷阱：指由一个实体引出的两种不同类型的扇形联系，形成双扇形结构。
2.2.3.数据库物理设计利用已确定的逻辑结构及DBMS提供的方法、技术。已较优的存储结构、数据存储路径、合理的数据存储位置及存储分配，设计一个高效可实现的物理数据库结构。
3. 模式数据库三级模式结构：这是数据库管理系统内部的系统结构。
3.1 概念模式只涉及行的描述，不涉及具体的值。概念模式的一个具体值称为模式的一个实例，同一模式可以有很多实例。概念模式反映的是数据库的结构及其联系，所以是相对稳定的。而实例反映的是数据库某一时刻的状态，所以是相对变动的。 概念模式不仅要描述记录类型，还要描述记录间的联系、操作、数据的完整性、安全性。但概念模式不涉及存储结构、访问技术等细节。
3.2 外模式也称用户模式或子模式。是用户与数据库系统的接口，是用户用到的那部分记录的描述。由若干外部记录组成，用户使用DML（数据操作语言）操作外模式的外部记录。
3.3 内模式也称存储模式，是数据库物理结构和存储方式的描述，是数据在数据库内部的表示方式。定义所有内部记录的类型、索引、文件的组织方式。记录的存储方式是顺序存储、B树存储、Hash方法存储等。 两级映像：模式/内模式映像、外模式/模式映像。 实体与记录：实体表示客观存在，能区别的事物。记录是字段的有序集合，一般一条记录描述一个实体。 属性与字段：属性描述实体某方面的特性，字段标记实体属性的命名单位。 码与记录码：码是唯一能区分实体的属性或属性集，记录码是唯一标识文件中的每条记录的字段或字段集。 实体集与文件：实体集是具有共同特性的实体的集合。文件是同一类记录的汇集。 实体型与记录型：实体型是属性的集合，记录型是记录的结构定义。
3.4 数据模型三要素数据库结构的基础是数据模型，是用来描述数据的一组概念和定义。 数据模型三要素是数据结构、数据操作、数据的约束条件。 E-R模型：是实体-联系模型的简称。所采用的3个主要概念是实体、联系、属性。 实体：现实世界中可以区别其它对象的物体或事件。 联系：实体的联系分为实体内部的联系和实体与实体之间的联系。 两个不同实体之间的联系： （1）一对一：指实体集E1中的一个实体最多只与实体集E2中的一个实体相联系。（1:1） （2）一对多：表示实体集E1中的一个实体可与实体集E2中的多个实体相联系。（1:N） （3）多对多：表示实体集中E1中的多个实体可与实体集E2中的多个实体相联系。（M:N） 两个以上不同实体集的联系： 两个以上不同实体集之间存在1：1：1、1：1：N、1：M：N和R：M：N 同一实体集内的二元联系： 同一实体集内的各实体之间也存在1：1、1：N和M：N的联系。 属性是实体某方面的特性。 派生属性可以从其它属性得来，例如：参加工作时间和工作年限，工作年限可以从当前时间和参加工作时间得到，这里工作年限就是一个派生属性。 概念模型中最常用的方法是实体-联系法，简称E-R方法。 扩充的E-R模型： 弱实体：这种实体对另一些实体有着很强的依赖关系，即一个实体的存在必须以另一个实体为前提。例如职工与家属的关系。 特殊化：一个实体集可以按照某种特征区分为几个子实体。例如：学生实体集可以分为研究生、本科生、大专生。我们称这种过程为特殊化，反之叫普遍化。 层次模型：采用树形结构表示数据与数据之间的联系。 网状模型：采用网状结构表示数据与数据之间的联系。 关系模型：在关系模型中以表格结构表达实体集，以及实体集之间的联系。 关系代数： 笛卡尔积：D1={0，1}、D2={a，b}。D1*D2={0,a}{0,b}{1,a}{1,b}。 关系的3种类型： 基本关系：实际存在的表，是实际存储数据的逻辑表示。 查询表：查询结果对应的表。 视图表：由基本表或其它视图表导出的表，由于它本身不独立存储在数据库中。数据库只存放它的定义，所以常称为虚表。 完整性约束： 完整性规则提供了一种手段来保证授权用户对数据库操作修改时不会破坏数据的一致性。 关系的完整性分为3类： （1）实体完整性：规定基本关系R的主属性A不能取空值。 （2）参照完整性：在关系模型中实体与实体间的联系是用关系来描述的。这样自然就存在着关系与关系间的引用。 （3）用户定义完整性：反映某一具体应用所涉及的数据必须满足的语义要求，由应用环境决定。 5种基本的关系代数运算：并、差、广义笛卡尔积、投影、选择。 扩展关系运算：交、连接、除、广义投影、外连接。 SQL支持三级模式结构：视图对应外模式，基本表对应模式，存储文件对应内模式。
3.4 索引数据库中索引与书籍中索引类似，利用索引可以快速查找整本书信息，无需阅读整本书。 数据库索引可以使数据库程序无需对整个表进行扫描，就可以在其中找到所需数据。 索引分为： 聚集索引和非聚集索引。 聚集索引是指索引表中索引项的顺序与表中记录的物理顺序一致的索引。 视图创建遵循如下规定： （1）子查询不允许有order by和distinct语句。 （2）with check option表示对update、insert、delete操作时保证更新、插入或删除的行满足视图定义的谓词条件（即满足子查询中的where后的条件表达式）。 （3）组成视图的属性列名或者全部省略或者全部指定。如果省略属性列名，则隐含视图由SELECT子查询目标列的主属性组成。 SQL的访问控制：数据库控制是控制用户的存储权限,由DBA来决定。 通过GRANT和REVORK将授权通知系统，并存入数据字典。
4. 规范化规范化：将关系模式从低一级范式转化成高一级范式的过程。 5NF包含于4NF包含于BCNF包含于3NF包含于2NF包含于1NF。 1NF定义：关系模式R中的每个分量是不可再分的数据项，则关系模式R属于第一范式。1NF冗余度大、引起修改的不一致性、插入及删除异常。 2NF定义：若关系模式属于1NF，且每个非主属性完全依赖于码，则关系模式属于2NF。即1NF消除了非主属性对码的部分函数依赖。 3NF定义：2NF消除了非主属性对码的传递函数依赖，则称3NF。3NF的模式必是2NF的模式。产生冗余和异常的两个重要原因是部分函数依赖和传递依赖。 BCNF（巴科斯范式）：即3NF消除了主属性对码的部分和传递依赖，称为BCNF。 4NF：4NF是限制关系模式的属性间不允许有非平凡且非函数依赖的多值依赖。 如果只考虑函数依赖，BCNF是关系模式最高的规范化程度。如果考虑多值依赖，4NF是关系模式最高的规范化程度。
5. 事务管理事务有4个特性ACID。 原子性（A）：要么全做，要么全不做。 一致性（C）：一个事务独立执行的结果，将保持数据的一致性，即数据不会因为数据的执行而遭受破坏。 隔离性（I）：一个事务的执行不能被其它事物干扰。 持久性（D）：一个事物一旦提交，对数据库的改变必须是永久的。 SQL中事物定义语句有3条： BEGIN TRANSACTION：事务开始。 COMMIT：事务提交。 ROLLBACK：事务回滚。
6. 并发控制并发控制主要技术是封锁，主要包含：排他锁（简称X锁或写锁）、共享锁（简称S锁或读锁）。 排他锁：若事务T对数据对象A加上X锁，则只允许T读取和修改A。其它事务不能对A加任何锁，直到T释放锁。 共享锁：若事务T对数据对象A加上S锁，则只允许T读取A，但不能修改A。其它事务只能再对A加S锁。保证其它事务可以读取A，但在T释放A上的S锁前不能修改A。 三级封锁协议： 一级封锁协议：事务在修改数据前必须先对其加X锁，直到事务结束才释放（结束包括commit或rollback）。一级封锁协议解决丢失更新的问题。 二级封锁协议：在一级协议的基础上，加上事务在读数据之前必须加S锁，读完后即可释放S锁。二级封锁协议解决读脏数据的问题。因为读完后即释放，所以不能保证可重复读。 三级封锁协议：在一级协议的基础上，加上事务在读数据之前必须加S锁，直到事务结束时释放S锁。除了防止丢失更新、读脏数据的问题，还进一步防止不可重复读。 活锁和死锁： 活锁：当事务T1封锁数据R，事务T2请求数据R于是T2等待。T1释放了R上的封锁，系统首先批准了T3的请求，T2继续等待，之后系统批准了T4的请求……依此类推，T2可能永久等待。这种现象称为活锁。 死锁：是指两个以上事务分别请求封锁对方已经封锁的数据，导致长期等待而无法继续进行下去的现象叫死锁。 并发调用可串行性： 多个事务并发执行，当且仅当其结果与某一次序串行地执行它们时的结果相同，我们称这种调度是可串行化调度。 给定一个并发调度，当且仅当它是可串行化的才认为是正确调度。 两段封锁协议：指所有事务必须分为两个阶段对数据项加锁和解锁。 第一阶段是获得封锁：事务可以获得任何数据项上的任何类型的锁，但不能释放。 第二阶段是释放封锁：事务可以释放任何数据项上的任何类型的锁，但不能申请。 事务是不能嵌套的，因为这违背了事务的原子性。事务是不能嵌套是指当且仅当当前没有事务在运行时，程序才能执行BEGIN TRANSACTION操作。 通过Resource授权来控制创建新关系的能力，具有Resource授权的用户在创建新关系后自动获得该关系上的所有权限。作者：小潭渔
本文梳理了在使用Redis过程需要遵循的一些最佳实践，包括针对架构维度的一些深入性能优化的知识，如果面试官问你："说下在使用Redis的过程中，需要注意哪些规范？"，如果你按照本文的思路回答，肯定能让面试官眼前一亮，offer自然就到手了。
第一节 数据库设计概述设计者需要拥有计算机专业知识和应用业务经验。一 数据库生命周期二 数据库设计目标①满足应用功能需求②良好的数据库性能三 数据库设计内容数据库设计是从用户对数据的需求出发，研究并构造数据库的过程。（1）数据库结构设计：模式和子模式（2）数据库行为设计：通常通过应用程序实现四 数据库设计方法是数据库设计更加合理的指导原则。可以分为三类：①直观设计法②规范设计法③计算机辅助设计法（
目录第1关：从概念模型到MySQL实现第2关：从需求分析到逻辑模型第3关：建模工具的使用第1关：从概念模型到MySQL实现任务描述将已建好的概念模型，变成MySQL物理实现。# 请将你实现flight_booking数据库的语句写在下方： # 请将你实现flight_booking数据库的语句写在下方： drop database if exists flight_book
数据库设计是开发过程中至关重要的一步，合理的数据库设计能够提高系统的性能、可维护性和可扩展性。本文将介绍数据库设计规范，包括命名规范和字段类型选择。 一、命名规范 表名和字段名使用小写字母，单词之间使
目录规范背景与目的设计规范2.1数据库设计2.1.1库名2.1.2表结构2.1.3列数据类型优化2.1.4索引设计2.1.5分库分表、分区表2.1.6字符集2.1.7程序DAO层设计建议2.1.8一个规范的建表语句示例2.2SQL编写2.2.1DML语句2.2.2多表连接2.2.3事务2.2.4排序和分组2.2.5线上禁止使用的SQL语句1.规范背景与目的MySQL数据库与Oracle、SQLSe
今天开始给大家分享数据库设计规范，希望感兴趣的朋友可以多来捧场。1.目的对数据库设计提出要求并制定规范和标准，以便在系统设计及软件编程过程中参考。在一个设计团队中，采用统一的设计规范，以保证开发出高可管理性的高质量系统、能够快速的进行开发、以及减少维护代码的时间。规范sql的编写格式，提高SQL语句的可读性，共享性和执行效率。如图所示设计原则：建立软件设计原则，形成约定；
1.数据库命名规范1.1.命名规范 命名对象包括文件、类、过程、函数、模块、变量。 尽量使用英文。在英文不好表达其含义时，可使用汉语拼音。 名称应能反映所代表对象的实际内容和作用。可使用多个词组合，但不要使用人名、项目组名。 只可使用字母、数字和连字符‘_’，但第一个字符必须是字母。 多个词组合较长时可使用缩写，但尽
怎么设计一个好的数据库？首先必须有一个好的数据库设计规范。本数据库设计规范范例共分几个部分：目的、适用范围、规范说明、标准词汇、命名规范、编码规范、数据字典书写格式 、E-R图的绘制模式、数据库后期维护的要求。可直接拿来用到工作中去。
# Java数据库设计规范初学者指南在软件开发中，数据库的设计是至关重要的一环。有效的数据库设计不仅能提升系统性能，还能确保数据的完整性和可维护性。本文将带你了解《Java数据库设计规范》的实施流程，并逐步介绍代码实现的细节。## 一、数据库设计流程概览在开始之前，我们需要明确完成数据库设计的步骤。以下是数据库设计的基本流程：| 步骤 | 描述
在这里总结一点吧，方便以后的使用 代码数据库设计规范数据库表命名规范 此规范包
放假前给大家介绍了数据库设计规范（一），今天继续我们的数据库规范。 若数据库数据元素多，在设计上有必要成立专门的数据小组。由于数据库设计者不一定是使用者，对系统设计中的数据元素不可能考虑周全，数据库设计出来后，往往难以找到所需
1引入三大范式• 必须保证数据库设计的合理性 • 数据库设计关
遵守3NF 标准3NF 规定：
1.规范背景与目的MySQL数据库与oracle、sqlserver等数据库相比，有其内核上的优势与劣势。我们在使用MySQL数据库的时候需要遵循一定规范，扬长避短。本规范旨在帮助或指导RD、QA、OP等技术人员做出适合线上业务的数据库设计。在数据库变更和处理流程、数据库表设计、SQL编写等方面予以规范，从而为公司业务系统稳定、健康地运行提供保障。设计规范3.1 数据库设计以下所有规范会
今天lola为大家继续分享数据库设计规范（三），主要讲讲数据库优化。1、分类拆分数据量大的表对于经常使用的表（如某些参数表或代码对照表），由于其使用频率很高，要尽量减少表中的记录数量。例如，通过业务类别将数据拆分，则可以大大提高查询效率。2、索引设计对于大的数据库表，合理的索引能够提高整个数据库的操作效率。在索引设计中，索引字段应挑选重复值较少的字段；在对建有复合索引的字段进行检索时，应注意按
上次和大家分享了数据库设计规范（三），今天继续为大家分享数据库设计规范（四）主要从性能优化的角度来分析数据库设计规范。本规范涉及的数据库对象包括：数据库、数据表、字段、视图、函数、存储过程、触发器、索引。每一个数据表必须指定一个主键。如果数据本身没有明显的主键，可增加一个唯一键列作为主键，数据类型可以是uniqueidentifier或自动增长的整数。字符型字段尽可能使用可变长的字符类型。在长
数据库设计规范表达是与否概念的字段，必须使用 is_xxx的方式命名，数据类型是 unsigned tinyint（ 1表示是，0表示否） 任何字段如果为非负数，必须是 unsigned。 表名、字段名必须使用小写字母、数字、下划线组成的的蛇形命名法； 表名不使用复数名词，表名应该仅仅表示表里面的实体内容，不应该表示实体数量。 表的命名最好是加上“业务名称表的作用”。 库名与应用名称尽量一致。 禁
优先选择符合存储需要的最小的数据类型 原因 列的字段越大，建立索引时所需要的空间也就越大，这样一页中所能存储的索引节点的数量也就越少也越少，在遍历时所需要的IO次数也就越多， 索引的性能也就越差 方法 1）将字符串转换成数字类型存储，如：将IP地址转换成整形数据。 mysql提供了两个方法来处理ip ...
本篇主要是写一个基于UDPUser Datagram Protocol ⽤户数据报协议）的简单的回显服务器和客户端代码，Echo server。
城市街道、公园、河道等公共区域的随意丢弃垃圾，严重影响环境卫生与城市形象。传统依赖人工巡查的方式效率低、响应慢、成本高。本文将带您构建一套基于。
如果你也有类似的困难，你可能会想知道如何从电脑上卸载安卓手机上的应用程序。一些安卓应用程序与架构功能紧密相关，无法删除，否则会导致问题。尽管大多数应用程序都可以卸载，但逐个卸载可能会很繁琐。相反，你可能更倾向于从PC上卸载安卓应用程序，这更快且更便捷。本指南将解释如何从PC或Mac上卸载安卓应用程序 ...
本文详细介绍如何用Python爬取豆瓣电影Top250数据。通过requests库构建带重试策略的会话，BeautifulSoup解析HTML结构，csv保存数据，并加入time随机延时模拟真实访问。文章从分析网页结构开始，逐步实现爬虫功能，包括处理翻页、解析电影信息、应对反爬机制等。最终将排名、片名、评分等7项数据保存为CSV文件，完整演示了网络爬虫的实战流程。