0

我最近读到了应该如何避免游标。好吧，我想知道我对它们的使用是否合适。

我正在创建一个可以在线工作的脚本引擎（嵌入在页面中，服务器端）这个脚本引擎将被这个产品的“高级”最终用户使用。然而，该产品与数据库的工作量很大，并且脚本语言类似于 C，但简化为它也类似于 PHP。对于数据库，我基本上想要这样的语法，因为它是语言中可创建的最一致的语法，无需最终用户手动编写 SQL 代码（如果我们要让他们这样做，他们为什么不能跳过脚本引擎，因为它使生活更简单）。语法是这样的：

declare DataSet $data("tablename","OtherID="+$oid);
//Dataset(string tablename,string where_clause_addon)
$data["field1"]="the data of field... ";
$data.Next();  
$data["field1"]="The data of the next row";
$data[10]["field1"]="The data of the 10th row";

我通过为每个 DataSet 创建一个全局游标（我在应用程序中只使用 1 个连接）然后让全局游标跟踪当前行位置（它也是一个 SCROLL 和 UPDATE 游标）来在内部控制它。这让我的生活变得更加简单，否则我将被迫编写自己的 SQL 控件来对抗 .Net 糟糕的 DataReader。

游标的这种用法可以吗？请注意，包含这些脚本的页面将无法在全球范围内访问，它仅适用于客户（因此可能一次只能有 3-10 个用户）。

有没有人看到跟踪当前变量位置的更好方法？（因为这些能够处理未知模式的表）

另外，我在使用这样的游标时会遇到并发问题吗？（我的文档说游标对于连接是全局的，每个页面请求都会在现场建立一个新连接，因此用户不会共享连接）

4

1 回答 1

8

“我最近读到了应该如何避免游标。”

他们无法避免。

“我读过更多，游标不一定要避免，而是游标很慢，应该只在某些情况下使用。”

正确——在某些情况下。

尽量使用 SQL 语句来做。不要通过打开游标并执行一堆 if 语句来发明自己的 SELECT 处理逻辑：使用 WHERE 子句。不要通过打开游标并读取每一行来发明自己的 GROUP-BY 处理：使用 GROUP BY 子句。不要使用嵌套游标循环发明自己的连接算法：使用适当的 JOIN 子句。

不要使用游标发明自己的 SQL。使用 SQL。

通常，“不要使用游标”的人会说“不要使用游标重新发明 SQL 算法”。这不是一个宽泛的、模糊的“不要使用游标”。这是非常具体的建议：“学习 SQL，不要通过编写游标循环来解决知识空白。”

只要您不重新发明现有的 SQL 算法，就有许多事情必须使用游标。

不要迷恋“避免光标”。在“纯 SQL”中做尽可能多的事情是合理的。

当您绞尽脑汁进行光标/无光标编程时，不要进行过早的优化。只需编写您能做到的最好的 SQL，并尽早且经常地对性能进行基准测试。

如果您无法找出最好的 SQL，请在此处询问最好的 SQL——不要迷恋游标。

于 2009-08-18T15:27:06.013 回答