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，但需要性能非常好，可以通過存儲過程和編譯的查詢來優化性能