SAS 中的 SQL 直通
将 SQL Passthrough 工具与 SAS 一起使用有什么优势吗?
Are there any advantages of using SQL Passthrough facility along with SAS?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
将 SQL Passthrough 工具与 SAS 一起使用有什么优势吗?
Are there any advantages of using SQL Passthrough facility along with SAS?
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
接受
或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论(5)
虽然这个问题过于宽泛,但我可以提供一个过于宽泛的答案。
SAS 中的直通 SQL 允许您直接与数据库通信。 当您使用数据库特定功能时,这变得非常有利。 Oracle 的统计函数就是一个例子。 您不必担心 SAS 将如何处理您的编码或翻译您的 SQL。
此外,传递 SQL 在 SAS 端只需要很少的处理,这对我们来说也是一个好处。 如果您有一个非常繁忙的 SAS 盒子,您可以选择将处理逻辑直接发送到数据库。 这在不使用传递 SQL 的情况下也是可能的,但在使用它时您可以拥有更高程度的控制。
这绝不是详尽的好处列表,只是使用传递 SQL 的一些高级好处。 如果您有更具体的用例,我们可以讨论编码技术的具体差异。
Although this question is overly broad, I can provide an overly broad answer.
The pass-through SQL in SAS allows you to communicate directly with a database. This becomes very advantageous when you are using database specific functions. An example would be Oracle's stats functions. You do not have to worry about how SAS will handle your coding or translate your SQL.
Additionally, it has also been a benefit to us that Pass-through SQL requires very little processing on the SAS side. If you have an extremely busy SAS box, you can opt to send the processing logic directly to the database. This is possible without using Pass-through SQL, but you have a higher degree of control when utilizing it.
This is by no means an exhaustive list of benefits, simply a few high level perks to using pass-through SQL. If you have a more concrete use case, we can discuss the specific differences in coding techniques.
PROC SQL 会尝试将尽可能多的逻辑传递给数据库,但有时却做不到。 使用数据库中(或数据库的 SAS/ACCESS 引擎)中没有等效项的 SAS 函数将阻止将整个查询传递到数据库。 当查询未完全传递到数据库时,数据将被拉入 SAS 并在那里进行处理。 SQL 越复杂,最终在 SAS 中处理的可能性就越大。 这是一个比您想象的更大的差异的案例。
这实际上(至少通过 SAS 9.1.3)将所有与 flag=1 匹配的数据拉到 SAS,然后将其加载回数据库。 如果有数百万行,速度确实会变慢。
在这种情况下,您会发现显式传递速度要快得多。
我最近使用 Oracle 和一个包含大约 250,000 行的表做了一个示例。 第一种方法需要 20 秒,第二种方法需要 2 秒。
PROC SQL will try and pass as much of the logic as it can to the database, but there are various times that it cannot. Using SAS functions that do not have equivalent in the database (or in the SAS/ACCESS engine for the database), will prevent passing the whole query to the database. When the query is not fully passed to the database, then the data is pulled into SAS and processed there. The more complicated your SQL is the more likely it will end up being processed in SAS. Here is a case that makes a larger difference than you might realize.
This will actually (at least thru SAS 9.1.3) pull all the data that matches flag=1 down to SAS and then load it back into the database. It this is millions of rows it really slows down.
You would find explicit pass through much faster in this case.
I recently did an example using Oracle and a table with about 250,000 rows. The first way took 20 seconds and the second way to 2 seconds.
如果您不使用传递,则必须将所有记录(处理所需的)从数据库导入到 sas。 通过使用传递,您可以在数据库端完成一些处理,并仅将结果记录传送到 sas 中。 差异(在处理时间和网络使用方面)可能非常小,也可能很大,具体取决于您的操作。
If you don't use the pass-through, then you have to import all the records (that you need for the processing) from the database to sas. By using the pass-through, you can have some processing done on the database side and bring over only the resulting records into sas. The difference (in terms of processing time and network usage) can very, from tiny to huge, depending on what you do.
使用直通有很多优点,但这取决于您想要实现的目标。 一般来说,我在进行查询时使用标准的 proc sql,没有直通。 然而,最近我用它来生成一些存储过程。
显然,这不是在直通之外可以完成的事情(至少据我所知)。 所以是的……这完全取决于您想要实现的目标。
There are advantages to using passthrough, but it depends on what you're trying to accomplish. Generally, I use standard proc sql without the passthrough when doing queries. Recently, however, I've used it to generate some stored procs.
Clearly, that's not something that can be done outside of passthrough (at least not that I know of). So yea ... it all depends on what it is you're trying to accomplish.
简而言之,SQL 传递语句使您可以更好地控制发送到数据库的内容。
Put simply, SQL pass-through statements give you more control over what gets sent to the database.