使用存储过程的前提：
1，没有移植的问题，比如做的是一产品，客户要求不同的数据库，这时将逻辑放到存储过程上就不好移值，放到代码中则好很多。
2，项目规模比较小，如几千人使用的企业级系统，很少考虑复杂的分库分表分服务器

最佳策略：尽量不用存储过程

在规模小时，如几千人使用的企业级系统：
方案：
对于简单的查询，尽量不用存储过程,联合表可用视图，这样做的好处有二：
1，用视图分页的话可以通过底层框架生成通用的分页，而用存储过程需要对每个sql写rownumer之类
2，用视图页面可通过代码生成工具很容易直接生成，开发效率高。
对于复杂的查询或者事务更新可以使用存储过程，一是利用存储过程预编译的特点提高效率，并且逻辑都在数据库里，避免了多次查询。二是更改逻辑比较方便，不用打开项目，修改再部署，并且动到了bin的话，还会引起系统重新编译。（当然第二种好处适合小项目，对稳定性要求不高，不会因改错了一个逻辑，耽搁5分钟就会有大量投诉。）

参考：大型系统必须得要存储过程和触发器吗？

1，测试
2，监控
3，预案建立,防止问题出现时思维混乱
出现问题时想彻底解决方案！杜绝再次发生。
对于技术，如网站与系统，关键就是做好三点，速度、稳定性、安全性
安全性：可能发生的一定会发生
1，学好攻，做检测
2，做好防，服务器限制IP访问，策略，权限，默认端口，账号更改(sa,administrator)
3，做好预警，异常系统登陆日志，异常数据库连接，服务器新文件添加

关于监控，对于功能来说，核心功能在上线后要做好数据统计，分析是否有异常数据产生。
如一次上线积分产品，功能完成后，基本数据未修改，造成本不是积分产品的产品当成积分产品下，造成损失！

上线阶段：
1，开发：代码审查与TDD测试
2，上线：eventvwr分析与IIS日志
3，上线后:总结

对于新的项目流程
1，确定流程图
2，画出原型图
3，开发，代码审核与TDD
4，上线
5, 定期召集开会，看现有什么问题，改进【监控】

--多状态一字段存储，避免增加状态需要再新增字段的事情。sqlserver中set值即是类似存储
--创建状态表,用二进制上的1标识是否，生成身份值在建立表是指定，据身份值取状态，只需进行与运算即可
--可扩大，比如8进制，每位上可有8个选择,--假如有7种状态，则可用一个字段标识出56种选择
DROP TABLE #MyStatus
GO

CREATE TABLE #MyStatus( StatusName NVARCHAR(100),StatusValue INT )
INSERT INTO #MyStatus
VALUES('是否高',1) --1,001 二进制数位
INSERT INTO #MyStatus 
VALUES('是否富',2) --2,010
INSERT INTO #MyStatus
VALUES('是否帅',4) --4,100

SELECT *
FROM #MyStatus


--生成身份值
--张三
WITH zhangsan AS(
	SELECT '是否高' StatusName,1 StatusValue
	UNION SELECT '是否富' StatusName,0 StatusValue
	UNION SELECT '是否帅' StatusName,1 StatusValue
)
SELECT SUM(m.StatusValue) 张三身份值
FROM zhangsan z
JOIN #MyStatus m ON z.StatusName = m.StatusName 
WHERE Z.StatusValue = 1

--据身份值取出状态，李四身份值为3，查询各状态
SELECT m.StatusName,
CASE WHEN m.StatusValue & 3 = m.StatusValue THEN '是'
ELSE '否' END 
FROM #MyStatus m

1， 京东、淘宝这样的网上商城是综合性的，除按分类查询外，还要据属性进行进一步的筛选。它各种分类、各种产品都有，对应的产品属性是不一样的，将所有产品放到一张表中存储显然是不可取的，因为这样此表的栏位要多的不可想像，并且每种产品对应的属性栏位并不多，大部分栏位都浪费掉。
所以设计时：产品属性不能固化下来，而是要以行的形式存储。
对应结构为：
商品ID对应分类ID
分类ID对应属性组ID
商品属性ID对应商品ID、属性组ID、属性值
属性ID对应属性名称

2，而小一些的电子商城若只按分类查询，没有涉及属性的进一步的筛选，并且产品属于有限个种类，如保健药品类与健身器材类，因药类与器材类属性大部分相同，故分别开两张表即可：保健药品表、健身器材表。再加个产品与分类ID的关系表。

注：表设计的目的是将近相同属性的东西放到一块，有明显区别的需要拆分

方法1： 抓取订单表中当前最大的编号，进行加1产生新的编号
优点：简单
缺点：当订单表很大时，速度将慢下来

方法2：建立一mdCurrentNo表，取出此表的值并增加1
优点：此表只有一条数据，故速度很快。
缺点：编号只能是递增的。

方法3：建立一mdCurrentNo表，同时建立一mdOrderNo表，里面存储了提前生成的随机不重复编号，结构为ID,No, 而mdCurrentNo的值存放的就是ID值，每次取出此ID JOIN mdOrderNo的ID，得到编号，然后将ID+1
优点：灵活
缺点：需要定时生成mdOrderNo的记录

最具体的功能到底需要哪些，需要做到多细，都要由哪些详细的功能也都没了解，最终有多少个工作量？有没有参考例子
这个功能倒是那个部门用？有几个人用？都有谁谁来用？真的是单机版就可以了吗？
新项目如何正式上线？老数据如何倒入，什么时候导入？新系统如何测试？2个系统如何平滑衔接？
有没有签订正规的合同

1,商务通存数据，一种方式是存放到数据库中，客户的录入的信息存放数据库，然后客服端定时读取。这种的频繁对数据库的读写，且数据在磁盘上，速度、效率很有影响。另一种方式是在内存中设置一共享区如建立一static List集合，客户端向里面存，客服取，共同维护这一共享区，然后定时将此共享区的内容存入数据库即可。
至于客服端与服务器进行静态类共享的问题（即客服端与服务器共享服务器内存），可以利用web service来解决。在客户端点应用程序中添加服务器端的webservice,会自动引用服务器的命名空间，然后直接使用类即可。因为此类指定静态的，故做到了共享。 可参见PowerTalk的聊天信息存读方式。

即共享区用：static + webservice构造，static负责共享，webservice负责同一

Web Service本身其实是在实现应用程序间的通信。
客户端的概念是调用服务器上的远程过程，通常方式为实例化一个远程对象并调用其方法和属性。：服务器暴露出远程对象的接口，客户端就好像在本地使用的这些对象的接口一样，这样就隐藏了底层的信息，客户端也就根本不需要知道对象是在哪台机器上。

2, 将数据存放到内存中定时转储的方式属于NOSQL,代表之一Redis
Redis是一个key-value存储系统。和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)和zset(有序集合)。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，redis支持各种不同方式的排序。与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。

1M = 1024k
1K = 1024bit
1bit = 8位
一个整数占32位(4bit)，那么1M共可存放的整数个数为：1024*1024/4=262144个

题目：一个最多包含n个正整数的文件，每个数都小于n，其中n=10^7,且所有正整数都不重复。求如何将这n个正整数升序排列。
约束：最多有1MB的内存空间可用，有充足的磁盘存储空间。
直接读取所有文件入内存进行排序是不现实的，因为最多有1MB空间，最大可存放的数字是262144个
，可以分段取：从头到尾一段一段的取数据，在0-250000的放入内存并排序输出
从头到尾一段一段的取数据， 在250000-500000的放入内存并输出
从头到尾一段一段的取数据， 在500000-750000的放入内存并输出
从头到尾一段一段的取数据， 在750000-1000000的放入内存并输出

位图法排序:hash对应
定义一字符串，长度为10^7,初始每位为0，每位的顺序对应每个数字，分段读入数字，将对应位设置为1，
如：对于数字3，将此字符串的第三位设置为1即可。
然后输出为1的位数即可，不需排序。
与上边的方法相比，上边的方法要40次全文件扫描，而此方法仅需一次，并用结果不用排序
以空间换时间。

应用范围：1，知道上限。2，数字没有重复

推广：
给40亿个不重复的unsigned int的整数，没排过序的，然后再给一个数，如何快速判断这个数是否在那40亿个数当中
unsign int范围为0~2^32-1(4294967295≈5*10^9) 使用位图hash对应5*10^9/8/10^3/10^3 = 625MB.

1. 我们使用625M的字符串。每一位设置为0.
2. 将40亿个unsign int 遍历一遍。使用位图法将字符串中的对应位转化为1。
3. 读取“再给一个数i” 查看bit[i] 是否为1，1则有存在，0则不存在。

事件的完成中间要经过许多状态，如提交订单,订单审核通过,从北京移仓,抵达广州开始配货,广州发货,收货并确认等，客户在查询时须提供订单的状态，显示时若能以流程图的方式显式出来，告诉客户目前到哪个状态，还有几个状态则效果会很好。 如下：

1，随机产生，插入数据库之前判断数据库内是否存在，当数据量大时判断是否重复速度就比较慢。最好能产生时就保证唯一性。
2，随机产生 再加上主键，因为主键唯一，就保证了数据的唯一性。不过要先insert得到主键再update随机码。

常见的三层架构基本分为如下部分：

* 数据访问层DAL:用于实现与数据库的交互和访问，从数据库获取数据或数据库的部分。
* 业务逻辑层BLL:对上下交互的数据进行逻辑处理。
* 表示层WEB:主要是实现与用户的交互。
* 注：日常开发中，为了复用一些共同的东西，会把这些通过的东西抽象出来，以便在多个层中传递，如实体层Model，工具层Common

1，开放 – 封闭法则（OCP）

* 对扩展是开放的，对更新是封闭的。
* 可以添加新的代码来扩展系统的行为，但不能对已有代码进行修改。

2，Liskov替换法则（LSP）:子类应当可以替换父类并出现在父类能够出现的任何地方。

3，单一职责原则（SRP）:就一个类而言，应该仅有一个引起它变化的原因，即：每个类集中做好一件事，类的职责简单而集中。，在需求变化时，只修改一个地方。

4，依赖倒置原则（DIP）:

* 高层模块不应依赖于底层模块，两者都应依赖于抽象。
* 抽象不应依赖于细节，细节应依赖于抽象。
* 针对接口编程，不针对实现编程。

1，过程化：新增一种需求，相应增加一种方法，对应调用。

* 对过Switch,据传入的参数调用对应的方法，这些方法可能执行相同的流程，但不可固定下来。

2，对象化：新增一种需求，相应增加一种对象，通过多态来完成调用。核心的代码调控模块可以固定下来。

* 对过Switch,据传入的参数产生相应的对象，接着利用多态将流程固定下来。

3，XML配置化：新增一种需求，相应增加一条配置信息及对应的处理对象，核心代码读取需求并调用。(Spring)

* 无须Switch,配置文件中设置需求与类的关系，将需求读入列表中，将一种需求提出时，直接在配置文件中找到对应的类，调用之。
* 并且对象的更新与需要的对应在配置文件中完成，弹性非常好。
* 如：
//读取类信息填充成下拉表，据选择的值建立相应的类对象
* string mediatype = cbbMediaType.SelectedItem.ToString();
//得到类名
* string factoryDllName = ConfigurationSettings.AppSettings[mediaType].ToString();
//构造类对象
* ImediaFactory factory = (ImediaFactory)Activator.CreateInstance(“MediaLibrary”,factoryDllName).Unwrap();
* Imedia media = factory.CreateMedia();
* media.Play();

实现参见Gmail: 面向配置的程序设计

比如，客户表中有电话，但客户可能有多个电话，若按A电话/B电话插入，查询时录入B电话查，则须用like,或用全文检索，速度并不太快。
而在设计之初另存一表客户ID与tel,并设tel为主键，加聚集索引，则查询速度将飞快！

如2010-09-01 到 2010-09-03 的业绩
1，显示出三天的业绩总和。
2，2010-09-01 到 2010-09-03的业绩每天的明细业绩以图表形式展出。

变化的部门，一些设定的规则如退包扣几点提成等应放在XML或表中，这将修改时也就会很方便。若直接写到类中，类是编译过了再使用的，做修改时要重新生成类，不方便。

可以页面上放置一定数量的控件，隐藏掉，然后在增加数据时取出一个控件给值。这样降低了动态生成的复杂性。

一条记录中须有一个字段能标识出这条记录属于哪一类，这样便于功能的扩展与数据的统计，故一般要有类似type的字段

id
type
recordno
oldrecord
newrecord
position //在哪操作
lasteditby
lasteditdate

1，本地开发环境连接正式环境数据库测试
2，单步跟踪：程序中写日志，存储过程中存到操作表中，记录关键位置的操作信息，然后分析。