高效SQL查询之索引（V）
先站在应用程序的角度说说它们的不同。
1、 直接拼 SQL
就像大家了解的那样，直接拼 SQL 带来了 SQL 注入攻击，带来了拼时些许的性能损失，但是拼不用添加 SqlParameter ，会少写很多代码——很多人喜欢直接拼，也许就因为这点。这种做法会把你拼好的 SQL 原样直接发送到 DB 服务器去执行。（注意类似 ”exec yourproc ‘param1’, 12” 的语句不在此范畴，这是调用存储过程的一种方式）
2、 参数化 SQL
所谓的“参数化 SQL ”就是在应用程序侧设置 SqlCommand.CommandText 的时候使用参数（如： @param1 ），然后通过 SqlCommand.Parameters.Add 来设置这些参数的值。这种做法会把你准备好的命令通过 sp_executesql 系统存储过程来执行。通过参数化 SQL ，和直接拼 SQL 相比，最直接的好处就是没有 SQL 注入攻击了。
3、 调用存储过程
直接调用存储过程其实和参数化 SQL 非常相似。唯一的本质不同在于你发送到 DB 服务器的指令不再是 sp_executesql ，而是直接的存储过程调用而已。
很多人非常非常厌恶在应用程序中使用存储过程，而宁愿使用拼 SQL 或者参数化 SQL ，理由是它们提供了更好的灵活性——这个理由其实非常非常的发指（俺现在喜欢上这个词了）。
现在做设计，一般都是从上到下来，重心都在业务逻辑上。传说中的领域模型设计完，测试用例都通过之后，才会考虑数据持久化方式。数据持久化是系统的一部分，但绝对不是最重要的部分，设计应该围绕业务逻辑开展，持久化应该仅仅是个附件。至少，高层应用应该尽可能的不关心处于最底层的物理存储结构（如：表）和数据持久、反持久方式（是拼 SQL 还是存储过程），所以用不用存储过程根本不重要。很多人害怕存储过程，其实是害怕存储过程中包括业务逻辑——真实情况是，如果存储过程中包含了业务逻辑，那一定最初需求分析不够导致用例提取不足，导致测试用例覆盖不够，导致领域模型设计不充分，要不就是偷懒。
=====
站在 DB 角度讨论它们的不同，主要从 cpu 、内存方面来考虑，其他诸如安全性， msdn 上都有， google 也能拿到一堆资料，不再赘述。
首先是查询计划。
SQL 编译完一条 SQL 之后，会把它缓存起来（可以通过 sys.syscacheobjects 系统视图查看），以后再有相同的查询过来（注意 sys.syscacheobjects 视图中的 sql 字段，和它存储的东西完全一样才能称为&
相关文档：
大量的现代企业采用Web应用程序与其客户无缝地连接到一起，但由于不正确的编码，造成了许多安全问题。Web应用程序中的漏洞可使黑客获取对敏感信息（如个人数据、登录信息等）的直接访问。
Web应用程序准许访问者提交数据，并可通过互联网从数据库中检索数据。而数据库是多数Web应用程序的心脏。数据库维持着Web应用程序将� ......
删除表记录，快速删除表记录，删除表这些语句相信大家都会，下面整理一下Truncate、delete、drop用法区别：
相同点
truncate和不带where子句的delete, 以及drop都会删除表内的数据
不同点:
1. truncate和 delete只删除数据不删除表的结构(定义)
drop语句将删除表的结构被依赖的约束(constrain) ......
转载 SQL中的datetime用法详解
转载地址：http://blog.sina.com.cn/s/blog_495491770100fq4n.html
2009-07-27 09:45 sql server2000中使用convert来取得datetime数据类型样式
日期数据格式的处理，两个示例：
CONVERT(varchar(16), 时间一, 20) 结果：2007-02-01 08:02
时间一般为
getdate()
函数或数据表里的 ......
大型系统的生产环境，一般情况下，我们评价一条查询是否有效率，更多的是关注逻辑 IO( 至于为什么，回头补一篇 ) 。我们常说，“要建彪悍的索引”、“要写高效的 SQL ”，其实最终目的就是在相同结果集情况下，尽可能减少逻辑 IO 。
1.1 where 条件的列上都得有统计信息。
......
先说说这些误区。所谓“误区”，有一些是新手很容易犯的错误或者很容易忽略的问题，另外一些，则是像“耗子吃了盐会变成蝙蝠”一样，让我们从小就认为是正确的事情。如下：
1、 表上不管用得着用不着，都加个聚集索引。
我们知道，表以两种方式组织物理存储：有聚集索引的“聚集表&r ......
