我应该在这里使用SQL游标吗？

我最近读到关于如何避免使用游标的文章。嗯，我想知道我使用它们是否合适

我正在创建一个可以在线工作的脚本引擎（嵌入在页面中，服务器端）。此脚本引擎将由本产品的“高级”最终用户使用。然而，该产品在数据库中工作非常频繁，脚本语言类似于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";

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

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

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

另外，我使用这样的游标在并发性方面会有什么问题吗？（我的文档说，游标是连接的全局性的，每个页面请求都会当场建立一个新连接，因此用户不会共享连接）

“我最近读到了有关如何避免游标的内容。”

它们是无法避免的

“我读到的更多内容是，不一定要避免使用游标，而是游标速度慢，只能在某些情况下使用。”

正确--在某些情况下

尽可能多地使用SQL语句。不要通过打开一个游标并执行一系列if语句来发明自己的SELECT处理逻辑：使用WHERE子句。不要通过打开游标并读取每一行来发明自己的分组处理：使用GROUPBY子句。不要使用嵌套的游标循环来发明自己的联接算法：使用适当的联接子句

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

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

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

不要过分崇拜“避免使用光标”。在“纯SQL”中做尽可能多的事情是合理的

在光标/无光标编程时，不要过早进行优化。只需编写尽可能好的SQL语句，并尽早、经常地对性能进行基准测试

---

如果你不能找出最好的SQL，请在这里询问最好的SQL——不要迷恋游标。

你能解释一下，仅仅使用SQL能带来什么好处吗。我不确定我是否理解它的用途。你到底在说什么？您是否将该“脚本”转换为查询？是的，它将转换为查询。我们更喜欢避免使用直接SQL。（我知道where_子句的东西很粗糙，它会被改进）所以你把光标放在查询的结果上？这是你的问题吗？是的，这足够有效吗？每当脚本需要时，我使用光标读取、更新和插入行。。然后，当页面更新完成时，光标被销毁。