Since you're being so nice! Here is something else you might try. Part of the power of DBIC is the chained ResultSet. Customizing them with semantically significant names (beware shortcut names) can let you build up an amazing set of chained stuff. For example–

package LIBL::Schema::ResultSet::PlayerDataCurr;
use strict;
use warnings;
use parent "DBIx::Class::ResultSet::HashRef"; # <-Nice alternative to 
+DBIx::Class::ResultSet.

sub teams {
    +shift->search({ team_libl => { '!=' => undef } });
}

sub teams_rs { scalar +shift->teams }

sub with_id_static {
    +shift->search({}, { prefetch => [ 'id_static' ] });
}

sub with_id_static_rs { scalar +shift->with_id_static }

1;

__END__

=pod

=head1 Do you even Pod?

L<JSON> + L<DBIx::Class::ResultSet::HashRef> for speedy delivery.

  use JSON;
  for my $team ( $player_curr_model->teams->hashref_rs->all )
  {
      print encode_json($team), $/;
  }

  # OR
  my @teams = $player_curr_model
                ->teams
                ->with_id_static;

=cut
[download]

So, that is pretty contrived (and again UNTESTED) with splitting the with_id_static out but I think you can see how to put it back into the other sub and mix and match and build up chained calls that keep it very semantic and easy to test, repurpose, and maintain. DBIx::Class::ResultSet::HashRef is a regular ResultSet class with shortcuts to avoid the penalty of inflating data to objects when you prefer.