1、数据逻辑的放在一块
2、业务逻辑的放在一块
3、作界面的只做界面
4、最小网络传输
－－－－－－－－－－－－
1、数据逻辑的放在一块
比如，表：History
那么，存储过程：spWriteHistory 表示数据逻辑：就是对History的写操作
同样，存储spQueryHistoryFromHistoryID表示根据HistoryID对History记录的查询
再同样，spQueryHistoryFromHistoryID;2（;不是普通的分号，是存储过程组）表示HistoryID对History记录查询的另外一个类似的方法
2、业务逻辑
比如，还书,则spReturnBook
购买,则spBuyBook
此时可能要调用很多表，或很多数据逻辑：
如
Create Proc spBuyBook(
@iBookID int, --书ID
@iOperatorID int --操作员ID
)
-------------------------------------------
--Name: spBuyBook
--Func: 购买一本书
--Var: 见上
--Use: spWriteOperateRecord,spProc2,spProc3....
--User: Chair3,Chair4
--Author: Chair3 # SapphireStudio (www.chair3.com)
--Date :
--Memo : 临时写写的，给大家作个Sample
-------------------------------------------
AS
Begin
Begin Tran
--数据逻辑：更新Book表，减少数量
Update Book
Set BookNumber=BookNumber-1
Where BookID=@iBookID
...
--业务逻辑：写入操作记录
Exec spWriteOperateRecord '某某人出售了一本书，书的ID为XXX'
...
Commit Tran
End
不要试图一个存储过程做完所有的事情，应当考虑将部分代码分为更小的存储过程，以达到代码公用以及可维护性。
当然，要求性能很高的部分，最好还是单独完成。
3、界面的程序不要直接调用数据表。
俺在赛格的时候，不允许其他同事直接读取表的，他们只能有调用 Store Procedure 的权限.
这个根据开发环境而定,当然不是绝对,尽量如此.
这样，可以降低因为修改数据表而要对所有程序修改，检查的后果。
4、最小网络传输
4.1 减少使用Select * ....语句 ，选择你只需要的数据，Select Fd1,fd2 From tb1
4.2 减少客户端对数据库表的直接操作（与3有点同）
4.2 避免在客户端对数据库的循环写操作,把循环转移到服务器来.
4.3 ……忘了…靠经验了
4点最为重要，许多人的程序速度很慢，都是由于网络传输过多的缘故。
最后小结：优秀的程序员更重于对整体上的设计、可维护性、可扩展性的设计。