1.SQL Server 2005中的存储过程并发问题
问：我在SQL Server2005中遇到了并发问题。我持有车票的公共汽车上有一些空闲的座位。我在插入销售的查票之前，需要查看是否还有空闲的座位。我的存储过程做的事情如下所示:
以下为引用的内容：
CREATE PROCEDURE add_ticket — parameters
问题就是两个过程可以同时读取空闲票数，并且都可以预约一张票，即使是那里已经没有空余的了。我需要一种方法来防止一个过程在另一个过程运行add_ticket程序，但是还没有插入一张新票的时候读取空票的数量。
解答: 你是正确的;更高的隔离级别也不会保证多个读者去同时去读取同一个数据行。然而，还有几种方法你可以完成这项工作。例如，你可以给每个座位分配一个惟一的标识符(意思是，惟一键——不一定是GUID)，并且创建一个描述哪些座位已经被预订了的表。在表上放一个 UNIQUE约束，你就可以确保同一个座位不会被插入两次了。
就是说，我认为一个更有趣的方法就是使用SQL Service Broker。你可以为每个公交建立一个会话，并且将这个会话的句柄存放在一个表中，读者在执行RECEIVE之前可以参考这个表。通过这种方式，读者就可以正确地过滤。公共汽车上的每个座位都插一个消息到队列中。读者就可以简单地RECEIVE到所需的消息(在这个过程中，预定公共汽车上的座位)。 Service Broker会确保没有消息会被接受两次，也就是说你不会再遇到并发问题了。
2.SQL Server 2005中的索引类别
问：SQL Server 2005中是否有新的索引类别了
解答: SQL Server 2005没有为关系表引入新的索引类型。基本上——聚簇和非聚簇索引是以B-trees的方式实现的——还仍然在应用。然而，SQL Server 2005确实包含了一些索引上的加强，不论是完全文本索引，还是对于XML数据，此外这些加强还可以改善一些与关系型索引有关的问题。
SQL Server 2005的完全文本索引特性是全新的，并且是重新编写的。要获得这个特性的信息，请阅读Nimish Khanolkar的MSDN广播文档，介绍SQL Server 2005中的全文本查找。
XML是SQL Server 2005中另外一个在方式上发生了巨大转变的内容。现在对于开发人员来说有第一流的XML数据类型可用了。这个类型支持Xquery查询语言，使用了这个类型的字段可以通过特殊格式的XML索引被索引到。要了解更多有关XML类型的信息，请查找MSDN 上的文章。
还有各种各样的有关T-SQL索引命令的加强。也许最令人感兴趣的就是新的“在线”索引类型，它允许数据库管理员在不需要把用户锁到表外面的情况下执行索引维护任务。这个很有可能标记着数据库管理员需要等到夜里3点才能打开维护窗口修正问题的状况的终结!
3.对于表和字段的常见名字约束
问：什么是常见的对表和字段的名字约束
解答：SQL Server 2000下的表和字段名称有1到128字节的限制，并且遵循用于标识的规则。
第一个字母必须是如下的一种:
· Unicode Standard 2.0中规定的字母。
Unicode对字母的定义包括:拉丁字母，从A到Z，除了来自其他语言的字母之外。
下划线(_)，at符号(@)，或者数字符号(#)
在SQL Server中以这些符号作为标识符的开始具有特殊的含义。一个以at符号（@）开头的标识符表示一个本地的变量或者参数。一个以数字符号（#）开头的标识符代表一个临时表或者过程。一个以两个数字符号（##）开头的标识符标识的是一个全局临时对象。
一些Transact-SQL函数的名字以两个at符号（@@）开头。为了避免与这些函数混淆，推荐你不要使用两个at符号（@@）开头的标识符。
接下来的字母可以是以下的任意几种：
Unicode Standard 2.0定义的字母
来自基础拉丁文或者其他语音的十进制数字
at符号（@），美元符号（$），数字符号（#），或者下划线
标识符绝对不能是Transact-SQL的保留字。SQL Server保留了一些大写和小写的保留字。内建的空间或者特殊的字母都不允许出现，尽管你可以在好的老版本的Northwind中看到它们包含了内建的空间。你必须通过把它们括在括号中才可以访问。
4.不具有任何T-SQL知识的情况下编写SQL Server2005存储过程
问：有没有可能在不了解T-SQL的情况下编写存储过程？ ］
解答：作为过去几年里面微软试图用SQL Server 2005的.NET集成来称霸市场的野心的结果，许多程序员都认为创建SQL Server存储过程不再必需T-SQL了。不幸的是（或者并非如此，这根据你的观点），这并不全是事实。在技术上是可以在不了解T-SQL的情况下创建存储过程的，但是没有T-SQL的话则无法访问任何的数据。
在CLR存储过程内部进行数据访问，是通过使用标准的ADO.NET类来完成的。开发人员会在应用程序层发现很多同样的没有用处的数据访问代码，这些代码会很轻易地转移到SQLCLR例程中去。当中间层的这些ADO.NET类需要使用T-SQL来访问数据的时候，在 CLR主机提供的环境中就会使用同样的类。
我要强调的是，从技术角度来说，不使用T-SQL来编写存储过程是可能的。那么有没有理由这么做呢？一种情况就是这是一个用来从普通文件或者网络服务中检索数据的CLR存储过程，并将数据格式设置为行集。这里可能就会用到不需要T-SQL的操作——但是这并不是对T -SQL存储过程能力的一个很好的比喻。
在大家以后遇到类似的开发问题时，本文可以作为大家的参考，希望文中的内容能够帮助到大家。