何时使用 $sth->fetchrow_hashref、$sth->fetchrow_arrayref 和 $sth->fetchrow_array?
我知道:
$sth->fetchrow_hashref
返回从数据库获取的行的 hashref,$sth->fetchrow_arrayref
返回从数据库获取的行的 arrayref,- $sth->fetchrow_array 返回从数据库中提取的行的数组。
但我想知道有关这些的最佳实践。我们什么时候应该使用 fetchrow_hashref ,什么时候应该使用 fetchrow_arrayref ,什么时候应该使用 fetchrow_array ?
I know that:
$sth->fetchrow_hashref
returns a hashref of the fetched row from database,$sth->fetchrow_arrayref
returns an arrayref of the fetched row from database, and$sth->fetchrow_array
returns an array of the fetched row from database.
But I want to know best practices about these. When should we use fetchrow_hashref and when should we use fetchrow_arrayref and when should we use fetchrow_array?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
当我为 $work 编写 YAORM 时,我在我们的环境 (MySQL) 中对所有这些进行了基准测试,发现 arrayref 的执行与 array 相同,而 hashref 慢得多。所以我同意,最好尽可能使用 array* ;它有助于让您的应用程序知道它正在处理哪些列名称。此外,您获取的列越少越好,因此请尽可能避免
SELECT *
语句 - 直接选择SELECT
。但这仅适用于企业应用程序。如果您正在做的事情对时间要求不高,请选择以您最容易使用的格式呈现数据的形式。请记住,在开始完善应用程序之前,效率对于程序员来说是最快的,而不是对于机器来说最快的。您的应用程序需要执行数百万次才能开始节省比编写代码所花费的时间更多的时间。
When I wrote YAORM for $work, I benchmarked all of these in our environment (MySQL) and found that arrayref performed the same as array, and hashref was much slower. So I agree, it is best to use array* whenever possible; it helps to sugar your application to know which column names it is dealing with. Also the fewer columns you fetch the better, so avoid
SELECT *
statements as much as you can - go directly forSELECT <just the field I want>
.But this only applies to enterprise applications. If you are doing something that is not time-critical, go for whichever form presents the data in a format you can most easily work with. Remember, until you start refining your application, efficiency is what is fastest for the programmer, not for the machine. It takes many millions of executions of your application to start saving more time than you spent writing the code.
与将结果作为 arrayref 或数组呈现相比,DBI 必须做更多的工作才能将结果呈现为 hashref。如果最大的效率是一个问题,您更有可能使用 arrayref 或 array。这是否真的可以衡量也许更有争议。
数组和 arrayref 之间可能存在更大的边际性能差异。
如果您发现按名称引用列更容易,则使用 hashref;如果使用数字可以,那么任何一个数组表示法都可以。
如果您要做的第一件事是从获取函数返回值,或者将其传递给其他函数,那么引用可能更明智。
总体而言,没有任何充分的理由使用其中一种而不是另一种。如果您不负责 SQL,Ed Guiness 强调的陷阱可能是决定性的。
DBI has to do more work to present the result as a hashref than it does as an arrayref or as an array. If the utmost in efficiency is an issue, you will more likely use the arrayref or array. Whether this is really measurable is perhaps more debatable.
There might be an even more marginal performance difference between the array and the arrayref.
If you will find it easier to refer to the columns by name, then use the hashref; if using numbers is OK, then either of the array notations is fine.
If the first thing you're going to do is return the value from the fetching function, or pass it onto some other function, then the references may be more sensible.
Overall, there isn't any strong reason to use one over the other. The gotcha highlighted by Ed Guiness can be decisive if you are not in charge of the SQL.
您可能比阅读 DBI 食谱 更糟糕/?node_id=127116" rel="nofollow noreferrer">gmax。
除其他外,它指出:
You could do worse than read DBI recipes by gmax.
It notes, among other things:
一般来说,我使用
fetchrow_hashref
(我通过在 SQL 中使用别名来解决具有相同名称的两列问题),但我会回退到fetch
(又名fetchrow_arrayref
)如果我需要它更快的话。我相信fetchrow_array
适合那些不知道如何使用引用的人。In general, I use
fetchrow_hashref
(I get around two columns with the same name issue by using alias in the SQL), but I fall back tofetch
(AKAfetchrow_arrayref
) if I need it to be faster. I believe thatfetchrow_array
is there for people who don't know how to work with references.自从将所有数据库代码切换为使用 DBIx::Class 以来,我没有使用它们中的任何一个。
I don't use any of them since switching all of my DB code to use DBIx::Class.