数据库的基本知识

存储过程：

存储过程处理比较复杂的业务时比较实用。
比如说，一个复杂的数据操作。如果你在前台处理的话。可能会涉及到多次数据库连接。但如果你用存储过程的话。就只有一次。从响应时间上来说有优势。
也就是说存储过程可以给我们带来运行效率提高的好处。
另外，程序容易出现 BUG 不稳定，而存储过程，只要数据库不出现问题，基本上是不会出现什么问题的。也就是说从安全上讲，使用了存储过程的系统更加稳定。

数据量小的，或者和钱没关系的项目不用存储过程也可以正常运作。mysql 的存储过程还有待实际测试。如果是正式项目，建议你用 sql server 或 oracle 的存储过程。数据与数据之间打交道的话，过程会比程序来的快的多。面试官问有没有用存储，实际上就是想知道前来面试的程序员到底做过数据量大的项目没。如果是培训出来的，或者小项目小公司出来的，对存储肯定接触的少了。

所以，要想进大公司，没有丰富存储过程经验，是不行的。

那么什么时候才可以用存储？对于数据量不是很大以及业务处理不是很复杂的小项目就无需要了么？
错。存储过程不仅仅适用于大型项目，对于中小型项目，使用存储过程也是非常有必要的。其威力和优势主要体现在：
  1.存储过程只在创造时进行编译，以后每次执行存储过程都不需再重新编译，而一般 SQL 语句每执行一次就编译一次,所以使用存储过程可提高数据库执行速度。
  2.当对数据库进行复杂操作时(如对多个表进行 Update,Insert,Query,Delete 时），可将此复杂操作用存储过程封装起来与数据库提供的事务处理结合一起使用。这些操作，如果用程序来完成，就变成了一条条的 SQL 语句，可能要多次连接数据库。而换成存储，只需要连接一次数据库就可以了。
  3.存储过程可以重复使用,可减少数据库开发人员的工作量。
  4.安全性高,可设定只有某此用户才具有对指定存储过程的使用权。

列出数据库中常用的锁及其应用场景
数据库中的锁是网络数据库中的一个非常重要的概念，它主要用于多用户环境下保证数据库完整性和一致性。各种大型数据库所采用的锁的基本理论是一致的，但在具体实现上各有差别。目前，大多数数据库管理系统都或多或少具有自我调节、自我管理的功能，因此很多用户实际上不 清楚锁的理论和所用数据库中锁的具体实现。在数据库中加锁时，除了可以对不同的资源加锁，还可以使用不同程度的加锁方式，即锁有多种模式，SQL Server中锁模式包括： 
1）共享锁
SQL Server中，共享锁用于所有的只读数据操作。共享锁是非独占的，允许多个并发事务读取其锁定的资源。默认情况下，数据被读取后，SQL Server立即释放共享锁。例如，执行查询“SELECT * FROM my_table”时，首先锁定第一页，读取之后，释放对第一页的锁定，然后锁定第二页。这样，就允许在读操作过程中，修改未被锁定的第一页。但是，事务 隔离级别连接选项设置和SELECT语句中的锁定设置都可以改变SQL Server的这种默认设置。例如，“ SELECT * FROM my_table HOLDLOCK”就要求在整个查询过程中，保持对表的锁定，直到查询完成才释放锁定。 
2）修改锁
修 改锁在修改操作的初始化阶段用来锁定可能要被修改的资源，这样可以避免使用共享锁造成的死锁现象。因为使用共享锁时，修改数据的操作分为两步，首先获得一 个共享锁，读取数据，然后将共享锁升级为独占锁，然后再执行修改操作。这样如果同时有两个或多个事务同时对一个事务申请了共享锁，在修改数据的时候，这些 事务都要将共享锁升级为独占锁。这时，这些事务都不会释放共享锁而是一直等待对方释放，这样就造成了死锁。如果一个数据在修改前直接申请修改锁，在数据修 改的时候再升级为独占锁，就可以避免死锁。修改锁与共享锁是兼容的，也就是说一个资源用共享锁锁定后，允许再用修改锁锁定。 
3）独占锁
独占锁是为修改数据而保留的。它所锁定的资源，其他事务不能读取也不能修改。独占锁不能和其他锁兼容。 
4）结构锁
结构锁分为结构修改锁（Sch-M）和结构稳定锁（Sch-S）。执行表定义语言操作时，SQL Server采用Sch-M锁，编译查询时，SQL Server采用Sch-S锁。 
5）意向锁
意 向锁说明SQL Server有在资源的低层获得共享锁或独占锁的意向。例如，表级的共享意向锁说明事务意图将独占锁释放到表中的页或者行。意向锁又可以分为共享意向锁、 独占意向锁和共享式独占意向锁。共享意向锁说明事务意图在共享意向锁所锁定的低层资源上放置共享锁来读取数据。独占意向锁说明事务意图在共享意向锁所锁定 的低层资源上放置独占锁来修改数据。共享式独占锁说明事务允许其他事务使用共享锁来读取顶层资源，并意图在该资源低层上放置独占锁。 
6）批量修改锁
批量复制数据时使用批量修改锁。可以通过表的TabLock提示或者使用系统存储过程sp_tableoption的“table lock on bulk load”选项设定批量修改锁。

数据库的三大范式 

第一范式（The First Normal Form）
第一范式是最低的规范化要求，第一范式要求数据表不能存在重复的记录，即存在一个关键字。1NF的第二个要求是每个字段都不可再分，即已经分到最小，关系数据库的定义就决定了数据库满足这一条。主关键字达到下面几个条件：
1． 主关键字段在表中是唯一的
2． 主关键字段中没有复本
3． 主关键字段不能存在空值
4． 每条记录都必须有一个主关键字
5． 主关键字是关键字的最小子集
满足1NF的关系模式有许多不必要的重复值，并且增加了修改其数据时疏漏的可能性。为了避免这种数据冗余和更新数据的遗漏，就引出了第二范式（2NF）。

第二范式（The Second Normal Form）
定义：如果一个关系属于1NF，且所有的非主关键字段都完全地依赖于主关键字，则称之为第二范式，简记为2NF。
为了说明问题现举一个例子来说明：有一个库房存储的库有四个字段（零件号码，仓库号码，零件数量，仓库地址），
这个库符合1NF，其中“零件号码”和“仓库号码”构成主关键字。
但是因为“仓库地址”只完全依赖与“仓库号码”，即只依赖于主关键字的一部分，所以它不符合2NF，
这样首先存在数据冗余，因为仓库数量可能不多。
其次，存在如果更改仓库地址时，如果漏改了某一记录，存在数据不一致性。
再次，如果某个仓库的零件出完了，那么这个仓库地址就丢失了，即这种关系不允许存在某个仓库中不放零件的情况。
我们可以用投影分解的方法消除部分依赖的情况，而使关系达到2NF的标准。
方法是从关系中分解出新的二维表，是每个二维表中所有的非关键字都完全依赖于各自的主关键字。
我们可以如下分解：分解成两个表（零件号码，仓库号码，零件数量）和（仓库号码，仓库地址）。
这样就完全符合2NF了。

第三范式（The Third Normal Form）
定义：如果一个关系属于2NF，且每个非关键字不传递依赖于主关键字，这种关系是3NF。
从2NF中消除传递依赖，就是3NF。比如有一个表（姓名，工资等级，工资额），其中姓名是关键字，
此关系符合2NF，但是因为工资等级决定工资额，这就叫传递依赖，它不符合3NF，
我们同样可以使用投影分解的办法分解成两个表：（姓名，工资等级），
（工资等级，工资额）。