﻿<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Gavin&#039;s Blog &#187; 数据库</title>
	<atom:link href="http://laigw.name/tag/%e6%95%b0%e6%8d%ae%e5%ba%93/feed" rel="self" type="application/rss+xml" />
	<link>http://laigw.name</link>
	<description>Keep it simple, stupid. Simplicity is beauty.</description>
	<lastBuildDate>Sun, 29 Jan 2012 07:14:51 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>PHP沉思录之一：工作模型与数据库访问接口</title>
		<link>http://laigw.name/post/177.html</link>
		<comments>http://laigw.name/post/177.html#comments</comments>
		<pubDate>Tue, 18 Nov 2008 07:58:31 +0000</pubDate>
		<dc:creator>Gavin</dc:creator>
				<category><![CDATA[PHP]]></category>
		<category><![CDATA[PAO]]></category>
		<category><![CDATA[工作原理]]></category>
		<category><![CDATA[工作模型]]></category>
		<category><![CDATA[数据库]]></category>
		<category><![CDATA[沉思录]]></category>
		<category><![CDATA[访问接口]]></category>

		<guid isPermaLink="false">http://www.laigw.name/?p=177</guid>
		<description><![CDATA[本文发表于《程序员》5月号，是一个系列的第一篇，目前想到的其他一些主题是：
　　
　　SQL注入问题
　　事件模型
　　AOP模型
　　UI Framework的实现
　　Template机制
　　
PHP沉思录&#8211;工作模型
　　
     PHP的工作模型非常特殊。从某种程度上说，PHP和ASP、ASP.NET、JSP/Servlet等流行的Web技术，有着本质上的区别。
     以Java为例，Java在Web应用领域，有两种技术：Java Servlet和JSP（Java Server Page）。Java Servlet是一种特殊类型的Java程序，它通过实现相关接口，处理Web服务器发送过来的请求，完成相应的工作。JSP在形式上是一种类似于PHP的脚本，但是事实上，它最后也被编译成Servlet。也就是说，在Java解决方案中，JSP和Servlet是作为独立的Java应用程序执行的，它们在初始化之后就驻留内存，通过特定的接口和Web服务器通信，完成相应工作。除非被显式地重启，否则它们不会终止。因此，可以在JSP和Servlet中使用各种缓存技术，例如数据库连接池。

     ASP.NET的机制与此类似。至于ASP，虽然也是一种解释型语言，但是仍然提供了Application对象来存放应用程序级的全局变量，它依托于ASP解释器在IIS中驻留的进程，在整个应用程序的生命期有效。
     PHP却完全不是这样。作为一种纯解释型语言，PHP脚本在每次被解释时进行初始化，在解释完毕后终止运行。这种运行是互相独立的，每一次请求都会创建一个单独的进程或线程，来解释相应的页面文件。页面创建的变量和其他对象，都只在当前的页面内部可见，无法跨越页面访问。在终止运行后，页面中申请的、没有被代码显式释放的外部资源，包括内存、数据库连接、文件句柄、Socket连接等，都会被强行释放。也就是说，PHP无法在语言级别直接访问跨越页面的变量，也无法创建驻留内存的对象。
     见下例：
　　

&#160;查看代码 PHP1
2
3
4
5
6
7
8
9
10
11
12
13
14
　　&#60;?php 
　　class StaticVarTester &#123; 
　　 public static $StaticVar = 0; 
　　&#125; 
　　 
　　function TestStaticVar&#40;&#41; &#123; 
　　 StaticVarTester :: $StaticVar += 1; 
　　 echo &#34;StaticVarTester [...]]]></description>
		<wfw:commentRss>http://laigw.name/post/177.html/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>对关系型数据库设计范式的理解</title>
		<link>http://laigw.name/post/47.html</link>
		<comments>http://laigw.name/post/47.html#comments</comments>
		<pubDate>Sat, 15 Nov 2008 03:16:49 +0000</pubDate>
		<dc:creator>Gavin</dc:creator>
				<category><![CDATA[DB/SQL]]></category>
		<category><![CDATA[数据库]]></category>
		<category><![CDATA[数据库范式]]></category>
		<category><![CDATA[范式]]></category>

		<guid isPermaLink="false">http://www.laigw.name/?p=47</guid>
		<description><![CDATA[所谓范式，是关系型数据库关系模式规范化的标准，从规范化的宽松到严格，分别为不同的范式，通常使用的有第一范式、第二范式、第三范式及BC范式等。范式是建立在函数依赖基础上的。 
函数依赖
定义：设有关系模式R(U)，X和Y是属性集U的子集，函数依赖是形为X→Y的一个命题，对任意R中两个元组t和s，都有t[X]=s[X]蕴涵t[Y]=s[Y]，那么FD X→Y在关系模式R(U)中成立。X→Y读作‘X函数决定Y’，或‘Y函数依赖于X’。
　　通俗的讲，如果一个表中某一个字段Y的值是由另外一个字段或一组字段X的值来确定的，就称为Y函数依赖于X。
　　函数依赖应该是通过理解数据项和企业的规则来决定的，根据表的内容得出的函数依赖可能是不正确的。

第一范式（1NF）
定义：果关系模式R的每个关系r的属性都是不可分的数据项，那么就称R是第一范式的模式。
    简单的说，每一个属性都是原子项，不可分割。
　 1NF是关系模式应具备的最起码的条件，如果数据库设计不能满足第一范式，就不称为关系型数据库。关系数据库设计研究的关系规范化是在1NF之上进行的。
第二范式（2NF）
定义：如果关系模式R是1NF，且每个非主属性完全函数依赖于候选键，那么就称R是第二范式。
    简单的说，第二范式要满足以下的条件：首先要满足第一范式，其次每个非主属性要完全函数依赖与候选键，或者是主键。也就是说，每个非主属性是由整个主键函数决定的，而不能由主键的一部分来决定。
    举个例子：
    有股票日行情表的主键是股票代码和交易日期组成。非主属性中有收盘价和成交量等，都是由主键，即股票代码和交易日期函数决定的，单独的股票代码或者交易日期都不能函数决定这些非主属性。如果这个表中有非主属性股票简称，则股票简称是可以由股票代码来函数决定的，这样股票简称这个非主属性就不是完全函数依赖于候选键，这样的设计就不满足第二范式。
第三范式（3NF）
定义：如果关系模式R是2NF，且关系模式R（U，F）中的所有非主属性对任何候选关键字都不存在传递依赖，则称关系R是属于第三范式。
    简单的说，第三范式要满足以下的条件：首先要满足第二范式，其次非主属性之间不存在函数依赖。由于满足了第二范式，表示每个非主属性都函数依赖于主键。如果非主属性之间存在了函数依赖，就会存在传递依赖，这样就不满足第三范式。
    举个例子：
    在股票基本情况表中，主键是股票代码，有非主属性所属一级行业和所属二级行业。根据业务规则，所属二级行业能够函数决定所属一级行业，这就表示存在这样一种关系：股票代码函数决定所属二级行业，所属二级行业函数决定所属一级行业，这就形成了传递依赖，这样的设计就不符合第三范式。
    不过在实际运用中，为查询和使用的方便，有时也会违反第三范式。如上例，如果没有所属一级行业的属性，需要查询所属一级行业的相关股票，需要查询时使用函数来从二级行业中函数生成所属一级行业，使用性能上会受影响。所以通常会加上所属一级行业的属性。
BC范式（BCNF）
BC范式是第三范式的增强版，不过也有人说是直接从1NF发展过来的，即每个属性，包括主属性或非主属性，都完全依赖于候选键，并且不存在传递依赖情况。
]]></description>
		<wfw:commentRss>http://laigw.name/post/47.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

