在C#源代码或存储过程中保留SQL有哪些优点/缺点？我一直在和一个朋友讨论这个问题，他正在做一个开源项目(C#ASP.NET论坛).目前，大多数数据库访问都是通过在C#中构建SQL内联并调用SQL Server数据库来完成的.所以我想确定，对于这个特定的项目，哪一个是最好的.
到目前为止，我已经:
在代码中使用的优点:
- 易于维护-无需运行SQL脚本来更新查询
- 更容易移植到另一个数据库-无需程序移植
存储过程的优点:
- 表现
- 安全
在C#源代码或存储过程中保留SQL有哪些优点/缺点？我一直在和一个朋友讨论这个问题，他正在做一个开源项目(C#ASP.NET论坛).目前，大多数数据库访问都是通过在C#中构建SQL内联并调用SQL Server数据库来完成的.所以我想确定，对于这个特定的项目，哪一个是最好的.
到目前为止，我已经:
在代码中使用的优点:
存储过程的优点:
我不喜欢存储过程
存储过程更易于维护，因为:
不管怎样，当数据类型发生变化，或者想要返回一个额外的列，或者诸如此类的时候，您都会重新编译它.总的来说，你可以"透明地"从你的应用下面修改SQL的次数非常少
- 最终会重用SQL代码.
包括C#在内的编程语言有一个惊人的东西，叫做函数.这意味着您可以从多个位置调用同一代码块！太神了然后，您可以将可重用的SQL代码放在其中一个代码中，或者如果您想获得真正的高科技，您可以使用一个为您实现这一点的库.我相信它们被称为对象关系映射器，现在非常常见.
当你试图构建一个可维护的应用程序时，代码重复是最糟糕的事情！
同意，这就是为什么StoredProc是件坏事.将代码重构并分解(分解成更小的部分)为函数比将SQL分解成函数要容易得多...SQL块？
你有4个Web服务器和一堆windows应用程序，它们使用相同的SQL代码.现在你意识到SQL代码有一个小问题，所以你宁愿......在1个位置更改程序或将代码推送到所有Web服务器，在所有windows框上重新安装所有桌面应用(clickonce可能有帮助)
为什么你的windows应用程序直接连接到中央数据库？这似乎是一个巨大的安全漏洞，也是一个瓶颈，因为它排除了服务器端缓存.他们不应该通过web服务或类似于您的web服务器进行连接吗？
那么，推送1个新存储过程，还是推送4个新的Web服务器？
在这种情况下，推送一个新的存储过程更容易，但根据我的经验，95%的"推送更改"会影响代码，而不是数据库.如果你当月向Web服务器推送20件东西，向数据库推送1件，那么如果你改为向Web服务器推送21件东西，向数据库推送0件东西，你几乎不会损失太多.
更容易查看代码.
你能解释一下怎么做吗？我不明白.尤其是存储过程可能不在源代码控制中，因此无法通过基于web的SCM浏览器等进行访问.
StoredProc存在于数据库中，在外界看来，它是一个黑匣子.简单的事情，比如想把它们放到源代码控制中，就会变成一场噩梦.
还有纯粹努力的问题.如果你想向你的首席执行官证明，为什么建立一些论坛只花了他们700万美元，而为每件小事创建一个storedproc只是额外的徒劳无益的工作，那么将所有内容分解为million tiers是有道理的.