SQL存储过程放在SQL数据库中，1，因此在程序中调用的时候不必自己拼接sql语句。2，SQLSERVER会对存储过程进行预编译，因此速度快。3，在网络上不必传输冗长的SQL语句，而是直接调用存储过程的名字，因此可以加快速度当然，在一些外包软件开发中，是不允许使用存储过程的。因为对方不可以把数据库暴露给你，此时你只能使用SQL语句。不过国内的一些小型企业使用SQL存储过程还是很流行的。因为程序代码里不包含SQL语句，因此会数据库会相对安全一些。
B. mysql存储过程为什么不推荐使用
维护不方便，对数据库压力不较大，不易于数据库集群的扩展和迁移。
能够在业务系统层面做的逻辑尽量不要用存储过程来做。
以后做数据库的迁移的时候，换了数据库，存储过程可能要重写或重构。但是如果放在业务代码层去实现对应的逻辑，数据库换了之后，更改对应的连接驱动，业务代码不用做任何吸怪。
C. 什么情况下才应该使用存储过程而不是用程序来对数据做操作
对于什么情况下才应该使用存储过程而不是用程序来对数据做操作的问题，我有下面的看法。
个人经验总结
OLTP类的应用可能需要更多的业务逻辑，而数据操作的复杂性和容量相对较小，甚至在应用程序层实现中，数据操作也不会产生太大的影响。
应用程序软件可移植性(DB独立性)，软件可能需要支持多个数据库，如Oracle或IBM数据库，应该支持上述应用程序。向应用程序层添加更多的数据操作逻辑可以减少对数据库存储过程的更改的需求，从而支持不同的数据库。
D. 请问.net为什么抛弃了linq to sql EF与linq to sql 相比较，前者有哪些优势
说是抛弃也不太对，因为这部分被合并在Linq to Entity里面了。
ADO.Net Entity Framework 与Linq to SQL的比较和适用场景：
MSDN上最近发表了一篇Elisa Flasko着的文章，比较了LINQ to SQL与LINQ to Entities适用的场景:
Introcing LINQ to Relational Data
http://msdn2.microsoft.com/en-us/library/cc161164.aspx
作者指出，LINQ to SQL主要的应用场景是针对微软SQL Server数据库的快速开发，这些应用的对象模型与数据库中数据定义的结构间非常类似，几乎有一一对应的映射关系，这样你可以使用LINQ to SQL把一些数据表直接映射到.NET类，数据字段映射到的相应的.NET类的属性上。作者总结如下：
LINQ to SQL适用之场景
.想使用ORM方案，而且数据库数据定义与对象模型是1：1对应关系
. 想使用ORM方案，而且对象继承结构储存在单一数据表中（单表继承）
. 想使用原始CLR类，而不是使用生成的类或需要从某个基类继承而来，或者需要实现某个接口
. 想使用LINQ来编写查询
. 想使用ORM，但需要性能非常好，可以通过存储过程和编译的查询来优化性能
LINQ to Entities主要的应用场景针对的是需要非常灵活和更复杂的映射的场景，特别是在企业应用方面，而且需要访问其他的数据库系统。在这些场景中，数据表的结构与对象模型也许差别很大，而且应用开发人员往往并不拥有生成或修改数据库数据定义的权利。
LINQ to Entities适用之场景 :
.想要开发针对微软SQL Server或其他数据库系统的应用
. 想要定义领域模型，并以之为持久层的基础
. 想要使用ORM方案，对象也许与数据库数据定义有1:1对应关系，也许结构迥异
. 想要使用支持单表继承和其他储存方案（每类一表，每具体类一表）的ORM方案
. 想使用LINQ来编写查询，并且查询可以在不同数据库系统下工作
. 想使用ORM，但需要性能非常好，可以通过存储过程和编译的查询来优化性能