Linux 何时使用 $sth->fetchrow_hashref、$sth->fetchrow_arrayref 和 $sth->fetchrow_array？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/3677160/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
When to use $sth->fetchrow_hashref, $sth->fetchrow_arrayref and $sth->fetchrow_array?
提问by user380979
I know that:
我知道：
$sth->fetchrow_hashrefreturns a hashref of the fetched row from database,$sth->fetchrow_arrayrefreturns an arrayref of the fetched row from database, and$sth->fetchrow_arrayreturns an array of the fetched row from database.
$sth->fetchrow_hashref返回从数据库中获取的行的 hashref，$sth->fetchrow_arrayref返回从数据库中获取的行的数组引用，并且$sth->fetchrow_array返回从数据库中获取的行的数组。
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?
但我想知道关于这些的最佳实践。什么时候应该使用fetchrow_hashref，什么时候应该使用fetchrow_arrayref，什么时候应该使用fetchrow_array？
回答by Ed Guiness
You could do worse than read DBI recipesby gmax.
It notes, among other things:
它指出，除其他外：
The problem arises when your result set, by mean of a JOIN, has one or more columns with the same name. In this case, an arrayref will report all the columns without even noticing that a problem was there, while a hashref will lose the additional columns
当您的结果集通过 JOIN 具有一个或多个具有相同名称的列时，就会出现问题。在这种情况下，arrayref 将报告所有列，甚至不会注意到存在问题，而 hashref 将丢失额外的列
回答by Chas. Owens
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 to fetch(AKA fetchrow_arrayref) if I need it to be faster. I believe that fetchrow_arrayis there for people who don't know how to work with references.
一般来说，我使用fetchrow_hashref（我通过在 SQL 中使用别名来解决两列具有相同名称的问题），但如果我需要它更快，我会回退到fetch(AKA fetchrow_arrayref)。我相信这fetchrow_array适用于不知道如何使用参考文献的人。
回答by Dave Cross
I don't use any of them since switching all of my DB code to use DBIx::Class.
我没有使用它们中的任何一个，因为我将所有数据库代码切换为使用DBIx::Class。
回答by Jonathan Leffler
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.
DBI 必须做更多的工作才能将结果呈现为 hashref，而不是将其呈现为 arrayref 或数组。如果最大效率是一个问题，您将更有可能使用 arrayref 或数组。这是否真的可以衡量可能更值得商榷。
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.
如果您发现按名称引用列更容易，则使用 hashref；如果使用数字没问题，那么任何一种数组表示法都可以。
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 Guinesscan be decisive if you are not in charge of the SQL.
总体而言，没有任何充分的理由使用其中一种。如果您不负责 SQL ，Ed Guiness强调的问题可能是决定性的。
回答by Ether
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 muchslower. 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 for SELECT <just the field I want>.
当我写YAORM为$工作，我为基准所有这些在我们的环境（MySQL的），发现数组引用执行相同的阵列，并hashref是很多慢。所以我同意，最好尽可能使用 array*；它有助于让您的应用程序知道它正在处理哪些列名称。此外，您获取的列越少越好，因此请SELECT *尽可能避免使用语句 - 直接转到SELECT <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.
但这仅适用于企业应用程序。如果您正在做的事情对时间要求不高，请选择以您最容易使用的格式呈现数据的任何形式。请记住，在您开始改进应用程序之前，效率对于程序员来说是最快的，而不是机器。您的应用程序需要执行数百万次才能开始节省比编写代码所花费的时间更多的时间。
