为了公司考勤系统的需要
编写的几个简单存储过程(可以手动运行,也可以设置事务自动运行!感觉还行比较通用,写出来共享下)
Calendar表结构很简单,2个字段:
fdDate 日期
fdType 考勤类型(工作日N,周末W,节假日H[需要根据需要自己修改])
--判断一段时间范围内的工作日（N）和周末（W）
Create     PROCEDURE [dbo].[NewMonthWeekDay_Calendar]
@sdate smalldatetime,
@edate smalldatetime
AS
declare @fdDate smalldatetime
declare @WeekDay varchar(20)
declare cr0 cursor for
 select fdDate from calendar where fddate>=@sdate and fddate<=@edate
open cr0
fetch next from cr0 into @fdDate
 while @@fetch_status=0
 begin
  if (datename(weekday,@fdDate)='星期一')
   update calendar set fdType='N' where fdDate=@fdDate
  if (datename(weekday,@fdDate)='星期二')
   update calendar set fdType='N' where fdDate=@fdDate
  if (datename(weekday,@fdDate)='星期三')
   update calendar set fdType='N' where ......

设计原则
 
符号三大范式（每一列表达一个意思，每一行代表一个实例/每一行有唯一键/表内没有其它表的非主键信息）
 
每个表应该有的3个有用字段（记录创建或更新时间/记录创建者/记录版本）
 
避免保留字
 
表应避免可为空的列


 
命名规范
 
表
表名如Order/UserAccout
符合以下规范：
1.     统一采用单数形式，反对Orders
2.     首字母大写，多个单词的话，单词首字母大写，反对order/Useraccout/ORDER
3.     避免中文拼音，反对AgentBaoCi
4.     避免下划线连接，反对User_Accout（下划线适用Oracle数据库）
5.     避免名称过长，反对WebsiteInfomationModifyRecord
6.     多对多关系表，以Mapping结尾，如UserRoleMapping
7.     避免保留字
 
字段
字段名如userID/userName/userType
符合以下规范：
1.     首个字母小写，多个单词的话，单词首字母大写，反对UserID/Userid
2.   ......

SQL Server 2000中，insert数据的时候返回自动编号的id，有三种方法实现SCOPE_IDENTITY、IDENT_CURRENT 和 @@IDENTITY，它们都返回插入到 IDENTITY 列中的值。
IDENT_CURRENT ：返回为任何会话和任何作用域中的特定表最后生成的标识值。IDENT_CURRENT 不受作用域和会话的限制，而受限于指定的表。IDENT_CURRENT 返回为任何会话和作用域中的特定表所生成的值。
@@IDENTITY： 返回为当前会话的所有作用域中的任何表最后生成的标识值。
SCOPE_IDENTITY ：返回为当前会话和当前作用域中的任何表最后生成的标识值
SCOPE_IDENTITY 和 @@IDENTITY 返回在当前会话中的任何表内所生成的最后一个标识值。但是，SCOPE_IDENTITY 只返回插入到当前作用域中的值；@@IDENTITY 不受限于特定的作用域。
使用示例：
set @NewID=SCOPE_IDENTITY()
set @NewID=@@IDENTITY
set @NewID=IDENT_CURRENT('表名')
例如，有两个表 T1 和 T2，在 T1 上定义了一个 INSERT 触发器。当将某行插入 T1 时，触发器被激发，并在 T2
中插入一行。此例说明了两个作用域：一个是在 T1 上的插入，另一个是作为触发器的结果在 T2 上的插入。假设 T1 和 T2 都有
IDENTITY 列，@@IDENTITY 和 SCOPE_IDENTITY ......

一、适合读者对象
数据库开发程序员，数据库的数据量很多，涉及到对SP(存储过程)的优化的项目开发人员，对数据库有浓厚兴趣的人。
二、介绍
在数据库的开发过程中，经常会遇到复杂的业务逻辑和对数据库的操作，这个时候就会用SP来封装数据库操作。如果项目的SP较多，书写又没有一定的规
范，将会影响以后的系统维护困难和大SP逻辑的难以理解，另外如果数据库的数据量大或者项目对SP的性能要求很，就会遇到优化的问题，否则速度有可能很
慢，经过亲身经验，一个经过优化过的SP要比一个性能差的SP的效率甚至高几百倍。
三、内容
1、开发人员如果用到其他库的Table或View，务必在当前库中建立View来实现跨库操作，最好不要直接使用“databse.dbo.table_name”，因为sp_depends不能显示出该SP所使用的跨库table或view，不方便校验。
2、开发人员在提交SP前，必须已经使用set showplan on分析过查询计划，做过自身的查询优化检查。
3、高程序运行效率，优化应用程序，在SP编写过程中应该注意以下几点：
a)SQL的使用规范：
i.　尽量避免大事务操作，慎用holdlock子句，提高系统并发能力。
ii.　尽量避免反复访问同一张或几张表，尤其是数据量较大的表，可以考 ......

Linq to SQL uses a DataContext to manage it's access to the database as well as tracking changes made to entities retrieved from the database. Linq to SQL has a persistent approach to managing its 'connection' to the database via this data context and it basically assumes that you use a single DataContext to make all of your data related access. This doesn't mean that it makes persistent connections to the database, but means that the DataContext instance maintains state about active result sets, which is especially important if change tracking is on which is the default.
This is somewhat contrary to other ORM tools which tend to have a static manager to which you pass entities or queries that are then returned. In that respect most other ORMs are stateless in their data connectivity and management object where LINQ to SQL clearly takes a connected approach where everything revolves around this single DataContext instance.  DataContext holds all the change management informatio ......

面向 OLTP 应用程序的重要 SQL Server 2005 性能问题
OLTP 工作负荷的特征是存在大量相似的小型事务。
在检查数据库设计、资源利用和系统性能的重要性时，请务必牢记这些特征。下面简述面向 OLTP
应用程序的重要性能瓶颈或缺陷。
数据
库设计问题
常用查询存在过多的表联接。在 OLTP 应用程序中过多使用联接将导致查询运行缓慢，
浪费系统资源。通常，应该重新设计数据库，避免需要 5 个或 5 个以上表联接的频繁操作。
频繁更新（包括插入、更新和删除）的表中存在过多的索引导致额外的索引维护开销。通常，OLTP 数据库的设计中应该将索引数保持为正常运转前提下的最小值，这同样是由于大量相似事务与索引维护成本共同作用的结果。
由于缺失索引，导致大量 IO，如表和范围的扫描。根据定义，OLTP 事务不应要求大量 IO，并且应该接受检查。
未使用的索引在插入、更新和删除中导致索引维护成本，而对任何用户都没有用。
应该清除未使用的索引。任何使用过的索引（通过选择、更新或删除操作）都出现在 sys.dm_db_index_usage_stats 中。因此，任何已定义但不包括在此 DMV 中的
索引自上次重新启动 SQL Server 以来尚未使用过。
CPU
瓶
颈
......