Yes, that works and is portable. However whenever I've dealt with code that tried to remember column names by position, it has been a maintainance issue. Every single time. (It wasn't always obvious to other people around me that it was a maintainance issue since the work of maintaining it and the routine failures in doing so were just accepted as normal.)

Therefore even though you can do things that way, I strongly recomment that you not do so. Albeit for different reasons than what I thought you were talking about.

I welcome ideas how to make the code independent on column position - I clearly expressed in the main article that I am waiting for other ideas how to convert the database relations to logic. The example is much complicated by the dependence on column order - but i don't know how to get rid of it in a simple way.

I tend to use raw DBI and fetchrow_hashref. Now I have columns by name. That won't be portable across databases (different databases handle capitalization of field names differently) but I've generally only found myself working with one database at a time so it isn't an issue for me.

Note that if you're processing large amounts of data, making those anonymous hashes is slower. I've never found that to be a bottleneck for me, but I've always had to deal with remote databases and have never worked with more than a few billion rows. (And on large datasets, my performance expectations were already set by the amount of data.) YMMV.