博客园-生为程序员，死做程序鬼-最新评论http://www.cnblogs.com/rainnoless/CommentsRSS.aspx.NET开始，JavaScript结束？zh-cnSun, 17 Oct 2010 14:01:39 GMTSun, 17 Oct 2010 14:01:39 GMTcnblogsre: 关于 T-SQL 的几点小九九 (1)http://www.cnblogs.com/rainnoless/archive/2009/06/08/1498362.html#1551694rainnolessrainnolessMon, 08 Jun 2009 11:47:56 GMThttp://www.cnblogs.com/rainnoless/archive/2009/06/08/1498362.html#1551694朝晖的.net: @楼主
2. 一个荒唐的 T-SQL 语句
最后楼主要表达的结论是什么？我一直没看明白。
我们到底应不应该用order by？
应用了order by（没有使用top）的标准查询返回的是一个游标，但是我们经常写这种eg：
select * from tableA where tableA.id = '***'
order by tableA.SortColumn;

楼主把结论告诉我吧··看得我点郁闷. :^(

4. 如何利用 T-SQL 编程满足一个苛刻的需求
对于特殊要求的列值，我们一般在程序里实现，把复杂逻辑写在脚本里，感觉维护成本有点高,我的拙见，我也是这么做的。楼主感觉呢？
--------------------------------------------------------

第一个问题就是，理论是上荒唐的，但是T-SQL却支持这种非标准的做法，如果在实践中我们找不到更好的途径快速解决问题的时候，我们使用了SELECT TOP ……ORDER BY来生成派生表的话，也无可厚非。
但是如果考虑到不同生产厂家的数据库产品之间迁移自己的SQL脚本的话，一切都按照 ANSI 的标准来编写 SQL 语句才是正确的做法，所以我给出的答案不在于我，而在于大家自己的实际情况，呵呵。

第二个问题，放在应用程序中处理也无可厚非，但是就这个我实际工作中的示例来说，对于我，利用 T-SQL 来实现的成本比在应用程序中利用更为复杂的逻辑实现更低，呵呵。


rainnoless 2009-06-08 19:47 发表评论
]]>re: 关于 T-SQL 的几点小九九 (1)http://www.cnblogs.com/rainnoless/archive/2009/06/08/1498362.html#1551688朝晖的.net朝晖的.netMon, 08 Jun 2009 11:36:43 GMThttp://www.cnblogs.com/rainnoless/archive/2009/06/08/1498362.html#15516882. 一个荒唐的 T-SQL 语句
最后楼主要表达的结论是什么？我一直没看明白。
我们到底应不应该用order by？
应用了order by（没有使用top）的标准查询返回的是一个游标，但是我们经常写这种eg：
select * from tableA where tableA.id = '***'
order by tableA.SortColumn;

楼主把结论告诉我吧··看得我点郁闷. :^(

4. 如何利用 T-SQL 编程满足一个苛刻的需求
对于特殊要求的列值，我们一般在程序里实现，把复杂逻辑写在脚本里，感觉维护成本有点高,我的拙见，我也是这么做的。楼主感觉呢？

朝晖的.net 2009-06-08 19:36 发表评论
]]>re: 关于 T-SQL 的几点小九九 (1)http://www.cnblogs.com/rainnoless/archive/2009/06/08/1498362.html#1551664rainnolessrainnolessMon, 08 Jun 2009 10:38:03 GMThttp://www.cnblogs.com/rainnoless/archive/2009/06/08/1498362.html#1551664耳根、请静: null 和 '' 之间有区别吗?
--------------------------------------------------------
在SQL中两者也截然不同，NULL 表示真正的空值，对于任何数据类型来说均是，等同理解为没有任何输入值。
而'' 表示的具体含义是空字符串，只出现在字符串类型(定长或者可变长)中，在SQL Server 中你看到是一片空白。

如果是在应用程序中显然也是有区别的，数据库中的空字符串对应于.NET 中的System.String.Empty，也就是我们常说的""。

在应用程序中，判断一个字符串是否为空值或者空字符串的方法，我自己封装如下：
#region 根据输入的字符串返回检查其是否为空引用或空字符串的结果的方法
/// <summary>
/// 作者：张亮
/// 功能：根据输入的字符串返回检查其是否为空引用或空字符串的结果
/// 时间：2008-06-24
/// </summary>
/// <param name="inputString">输入的字符串</param>
/// <returns>
/// isNullOrEmpty:
/// true 表示输入的字符串是空引用或空字符串
/// false 表示输入的字符串不是空引用或空字符串
/// </returns>
public static bool CheckStringIsNullOrEmpty(string inputString)
{
bool isNullOrEmpty = false;
string str = null;

/*
* 2008.10.8号 有必要重新回顾下当初写该方法的思路
* 如果不判断 inputString 是否为 null，而直接使用 inputString.Trim() 替换
* switch (str) 中的 str 的话，当 inputString = null 就会抛出异常。
*
* 为防止输入的字符串只作了声明(即赋值为null)，而并非在托管堆中分配空间，
* 则声明一个中间变量 str，当 inputString = null 其默认等价于 str = null，
* 而 inputString != null 时则将 inputString.Trim() 赋值给 str。
*/
try
{
if ( inputString != null)
{
str = inputString.Trim();
}

switch (str)
{
case null:
isNullOrEmpty = true;
break;
case "":
isNullOrEmpty = true;
break;
default:
isNullOrEmpty = false;
break;
}
}
catch ( Exception exp )
{
throw exp;
}

return isNullOrEmpty;
}
#endregion


rainnoless 2009-06-08 18:38 发表评论
]]>re: 关于 T-SQL 的几点小九九 (1)http://www.cnblogs.com/rainnoless/archive/2009/06/08/1498362.html#1551638耳根、请静耳根、请静Mon, 08 Jun 2009 09:54:02 GMThttp://www.cnblogs.com/rainnoless/archive/2009/06/08/1498362.html#1551638
耳根、请静 2009-06-08 17:54 发表评论
]]>re: 关于 T-SQL 的几点小九九 (1)http://www.cnblogs.com/rainnoless/archive/2009/06/08/1498362.html#1551617AsidyAsidyMon, 08 Jun 2009 09:35:58 GMThttp://www.cnblogs.com/rainnoless/archive/2009/06/08/1498362.html#1551617
Asidy 2009-06-08 17:35 发表评论
]]>re: 关于 T-SQL 的几点小九九 (1)http://www.cnblogs.com/rainnoless/archive/2009/06/08/1498362.html#1551588rainnolessrainnolessMon, 08 Jun 2009 09:20:17 GMThttp://www.cnblogs.com/rainnoless/archive/2009/06/08/1498362.html#1551588周强: 各位园友，我们不能读死书，我们要通过书中的所讲去理解，然后会思考。NULL确实会和SQL 带来额外的负担，但是我们是不是因为此就对NULL带有一种惯性的偏见呢？NULL和NOT NULL就性能和存储空间方面来说，我觉得不用做太多考虑，如果从程序的复杂度来说，倒是可以权衡一下。
--------------------------------------------------------
对于我来说，在应用程序中最讨厌处理的就是 NULL 值的情况，也常常成为我程序中隐形的BUG来源，所以当我获得一种能更好规避 NULL 值的做法时，我跟愿意在 T-SQL 程序相对编写复杂的脚本语句，而不愿意在应用程序中每每考虑字段是否存在空值的情况，如有该如何处理。
对于 NULL 的偏见并非来自于使用 T-SQL 编程和数据库，而是来自于应用层处理字段时各种需要考虑的逻辑判断。


rainnoless 2009-06-08 17:20 发表评论
]]>re: 关于 T-SQL 的几点小九九 (1)http://www.cnblogs.com/rainnoless/archive/2009/06/08/1498362.html#1551580rainnolessrainnolessMon, 08 Jun 2009 09:12:35 GMThttp://www.cnblogs.com/rainnoless/archive/2009/06/08/1498362.html#1551580那就讨论存储引擎吧。
SQL SERVER 2005和SQL 2000来比较，我觉着在存储&quot;格式&quot;方面，包括在工作原理方面，微软真没做什么改进，除了为了新功能特性的需要（比如表分区等）而导致了一些存储“格式”方面的变化外，其它几乎没什么变化。君不见《SQL 2000 技术内幕》与《SQL 2005 存储引擎》两本书在存储引擎方面95%的内容雷同？我猜想，SQL SERVER 2005有可能在存取算法上有所改进。

SQL SERVER 2005性能比SQL 2000好，我觉得SQL 2005在关系引擎和隔离级别方面倒是下了大功夫，存储引擎真说不准究竟有没有下功夫。
--------------------------------------------------------
其实推翻一个已经成熟的“工作原理”模型，建立一套新的体系真不是件容易的事情，微软举步维艰只是整个业界的一个缩影罢了。

Lubor kollar 听见你的话肯定会比较开心的，他引导的团队在关系引擎上还是应该下了不少功夫的。至于存储的一些底层算法的改进一定是有的，只是这样真正的内幕公布于市面主流的技术书籍之中，恐怕有失稳妥，呵呵。《SQL 2000 技术内幕》是一部巨头，我只是在书店翻阅过，未尝收入囊中，倒是 《SQL 2005 技术内幕》前三部已经堆积在床头，每日必读，而一直纳闷为什么不引进哪怕“调优”，哪怕是便宜的英文影印版也好，呵呵。这些书中的说描述的“内幕”对于我来说，更像是那些官方文档意犹未尽的细节之处，让人读了能够知其所以然，这样的数据读来，对于经历过实践折磨之后的我来说，受益良多，呵呵。


rainnoless 2009-06-08 17:12 发表评论
]]>re: 关于 T-SQL 的几点小九九 (1)http://www.cnblogs.com/rainnoless/archive/2009/06/08/1498362.html#1551573周强周强Mon, 08 Jun 2009 09:02:37 GMThttp://www.cnblogs.com/rainnoless/archive/2009/06/08/1498362.html#1551573
周强 2009-06-08 17:02 发表评论
]]>re: 关于 T-SQL 的几点小九九 (1)http://www.cnblogs.com/rainnoless/archive/2009/06/08/1498362.html#1551554周强周强Mon, 08 Jun 2009 08:50:07 GMThttp://www.cnblogs.com/rainnoless/archive/2009/06/08/1498362.html#1551554一个数据库产品的核心就是存储引擎，引擎的优良直接决定了这个产品的生命力，从我使用 SQL Server 2000 和 SQL Server 2005(使用时间不长)，每一次引擎的优化和升级带来的各种层出不穷的特性和性能上的提高是非常明显的。
SQL Server 2008刚出来那会使用过几天测试版之后再也没有触碰。在数据库上扑的时间越多，就会越发觉得自己需要了解和学习的东西实在太多，作为一个程序员，尤其是一个应用软件开发的程序员，多了解多关注一些数据库深层次的东东对于开发来说是非常有帮助的。

--------------------------------------------------------
那就讨论存储引擎吧。
SQL SERVER 2005和SQL 2000来比较，我觉着在存储"格式"方面，包括在工作原理方面，微软真没做什么改进，除了为了新功能特性的需要（比如表分区等）而导致了一些存储“格式”方面的变化外，其它几乎没什么变化。君不见《SQL 2000 技术内幕》与《SQL 2005 存储引擎》两本书在存储引擎方面95%的内容雷同？我猜想，SQL SERVER 2005有可能在存取算法上有所改进。

SQL SERVER 2005性能比SQL 2000好，我觉得SQL 2005在关系引擎和隔离级别方面倒是下了大功夫，存储引擎真说不准究竟有没有下功夫。

周强 2009-06-08 16:50 发表评论
]]>re: 关于 T-SQL 的几点小九九 (1)http://www.cnblogs.com/rainnoless/archive/2009/06/08/1498362.html#1551447rainnolessrainnolessMon, 08 Jun 2009 07:05:05 GMThttp://www.cnblogs.com/rainnoless/archive/2009/06/08/1498362.html#1551447sweepercn: 楼主那个关于生成唯一编码的逻辑有点看不懂，
以数据本表的planid的值本身做计数器，不就可以了，
为什么还要再去另找一表来做计数器？是不是有点把简单问题复杂化，原本只需要锁定一个表，现在一个事务锁定两个表，是不是太多余了。我想象的这样：
在本表里设planid维一值索引。
1、从本表最出最大数。
2、用TSQL语直接加1.
3、开始事务，插入数据。

还望楼主解惑。

--------------------------------------------------------
恩，您可能没有仔细看需求的由来，老板需要的变化规则如下：

例如现在是6月，那么生成的编号是 DP-P-09060001起始，一直到6月截止，按照业务需求最大量，采购发生的笔数不会超过 9999 笔，也就是我假设 6月最大的编号值为：DP-P-09069999。
那么到了7月份，DP-P-09070001 ~ DP-P-09079999
一下以此类推，之所以单独编写一个同步序列生成机，是为了能够没月1号00：00分后方式有数据插入发生，序列机会自动重新归零，从每月第一笔单开始重新计算，如果是使用你那种方式因为是不能满足这样的编号规则的。
其实，我这里还存在缺陷，我已经在 T-SQL 语句中用注释写明了，就是如果服务器时间被异常更改，如果是往后推迟了无所谓，现有规则依然可以运行，但是服务器时间被回拨，就是本来是6月，现在变成了5月，而5月的记录最大数值是DP-P-09051111，而此刻序列机中编号值为1000，那么此刻在插入数据，就会报错：PlanID 唯一性……。也就是说理应增加一道机制，检查插入的最后一个PlanID的年月份是否匹配，那么一旦发现日期异常，应该是去取出服务器当前月最大PlanID 的后4位值，写入到序列机中，从而继续在当前月的最后一个 PlanID 后继续连续生成新的 PlanID。
实在是有点绕，可能是我把问题复杂化了，考虑的东西太多了，等我沉静下来，把整个思路重新梳理成一篇文字，这样就方便理解了，呵呵。



rainnoless 2009-06-08 15:05 发表评论
]]>