连载：告诉你如何设计一个日访问量千万级别的系统，谈oracle的高级设计和开发（8）

会员登录模块，即会员输入会员名和密码，提交到后台进行登录的功能，这里面其实包含比较多的业务逻辑：

A）      判断会员名是否正确

B）      判断密码是否正确

C）      记录密码错误次数并明确告知登录者

D）      密码错误次数超过一定数量（通常由系统参数设置）锁定该账号一定时间，如24小时，锁定时间同样由系统参数设置；账号因为密码错误次数过多被锁定后，必须保证超过锁定时间后能正常登录操作，但若期间会员通过其他方式找回找回密码或者修改了密码，则本次锁定时间失效

E）      若账号正确，不管密码是否正确，每次登录提交操作，都记录登录日志，登录日志必须包含登录提交时间，IP地址等

F）       若涉及到积分的话，登录成功可能有送积分的需求。

等等

就用登录这个具体功能来说，会员输入用户名和密码点击登录按钮，要实现上述业务逻辑，技术上如何设计，会有很多方式。从性能及开发的简洁性来将，本人倾向于写一个用户登录的存储过程，传入会员登录名、密码、IP地址、登录方式（电脑、手机。。。）等，系统返回登录是否成功（若不成功，不成功的原因代码，每个代码对应一个含义，若是密码错误，则为第几次密码错误）以及该会员的会员ID。

本人在设计上述的业务逻辑，通常会选择设计一个存储过程进行处理。

 

这个观点亮出来后，估计看到的高手立即就会分为两派，因为在数据库中使用存储过程历来是数据库开发设计争论的热点之一。

本人也从关注过网上高手们对是否使用存储过程的各种论断，无非三种：不好，不能用；好，可以多用；适度使用。

每个人都能说出很多理由，而且理由都是站得住脚的。比方反对存储过程的理由：

A）      淘宝网不用存储过程。---这个论据非常有杀伤力

B）      存储过程不符合面向对象的设计理念。---这样说有些道理。

C）      存储过程维护起来很麻烦。--看似有些道理

 

本人在项目中会使用存储过程，但是有非常明确的使用原则，这些原则是十来年带团队开发各种项目总结出来的，接下来和大家分享一下这些观点，供高手们指正。针对存储过程，可以从以下四个角度来探讨这个问题。

1）、从数据安全角度思考

2）、从项目建设角度思考

3）、从项目维护角度思考

4）、从系统运行性能角度思考

 

本人使用存储过程的第一个原则：写数据使用存储过程，读数据不用。

不太严格地说，数据其实就是对现实世界中各种东西的科学定义，如描述一个杯子，通过大小、颜色、密度等等来科学定义。这个定义不能错误，错了一个数据，就是另外一个东西了；数据展示出来，则是多样的，搞艺术的看这个杯子，关注的是颜色等方面的数据，做生意的可能关注的是价格。

搞得像整哲学一样，没错。

项目中对数据同样可以分为两类操作：写数据（增删改）和读数据。而写数据必须是严格的，写出错影响数据安全；读数据是则是多元化的(不同场合读的字段是不同的，有些需要再加工，有些不需要)，读数据出错不会影响数据的安全。

当一个表有5,6个地方，甚至多个项目都在使用，都需要写操作，通过一个存储过程作为对外的写接口，是个很不错的选择。我只要保证存储过程对数据的写操作逻辑上是正确的，就能很大程度上保证数据的安全，将有五六处风险变成只有一处风险。读数据则不用存储过程，想怎么读就怎么读，对还是错都不影响数据安全。

待续