有一点复杂的查询采用子函数还是采用视图？
比如复杂一点的查询，

方案一、创建子函数fn_myfunction(@id as int)...
写出查询语句如下，

select id,dbo.fn_myfunction(id) from tab

结果正确，但是这样调用子函数，性能不好。

虽然数据量只有几十条，还是希望从提高性能的角度出发，所以考虑方案二，创建视图v_myview...

查询改为 

select tab.id,v_myview.data
from tab,v_myview
where ...

结果也是正确的。

那么使用视图是不是比较好呢？以后写，也总是沿着这样的思路走吗？自己对这一点不确定，数据量小所以两种方案的执行结果差别可能也不大。

目前工作中需要调取的数据量从没超过100条，所以其实影响不大。只是自己希望写查询的时候有这样的意识，想对自己严格要求，写出好的查询语句。

所以就这样的问题和大家讨论，请有经验的朋友多指导，多分享自己的经验。

------解决方案--------------------
如果只是
select id,dbo.fn_myfunction(id) from tab
那么都没有必要.

如果你只是从很多表中选取数据, 那么可以使用视图.
如果你需要对于选取的数据需要根据用户意愿(函数的参数)再做操作,那么就使用函数.
------解决方案--------------------
具体问题要具体分析，一般来说复杂的查询，肯定不要用视图。
视图本身只是一句查询SQL，并没有数据，你对视图的查询，等于视图再使用SQL代码去查询表，那你还不如直接对表查询更快。
至于函数，如果函数本身非常简单，比如大小写转换、四舍五入小数点等，可以使用，反正是查询出来结果集后再对这个结果集进行函数处理。但如果函数非常复杂，本身还要去查询其他表的话，那还是别用了。
所以一般的建议是，不管多复杂的查询，还是先直接对表查询开始。
另外，不管什么查询，容易出现的问题无非以下几种：
? 低质量的索引
? 不精确的统计
? 过多的阻塞和索引
? 不基于数据集的操作，通常是T-SQL游标
? 低质量的查询设计
? 低质量的数据库设计
? 过多的碎片
? 不可重用的执行计划
? 低质量的执行计划，通常是因为参数嗅探（parameter sniffing）所导致的
? 执行计划频繁重编译
? 游标的错误使用
? 数据库日志的错误配置
? 过多使用或者错误配置tempdb
在写代码的时候有意识避免，或者在数据库设计的时候有意识优化，也可以。
------解决方案--------------------
可以用子查询