I would probably not do it the way you've done it, from a user point of view.

To keep it simple and not over-implement, I usually design things like these to work as &foo below.

  sub foo {
    my @names = @_;
    ... ;
    return @values if wantarray;
    return $values[0];
  }
[download]

Even thought the implementation is explicit, I'd leave the behaviour for a "list call" in scalar context undefined in the documentation.

If I'd want to have it as a hash I could do

  my @ids = ...;
  my %foo;
  @foo{@ids} = foo(@ids);
[download]

or use my utility function &zip

  sub zip {
    my ($x, $y) = @_;
    map { $x->[$_], $y->[$_] } 0 .. max($#$x, $#$y);
  }

  my @ids = ... ;
  my %foo = zip(\@ids => [ foo(@ids) ]);
[download]

which is good when you don't want to use an intermediate variable.

A lot of the time I don't care to handle more than one argument though, because I often use map for that

  my @ids = ... ;
  my @foo = map foo($_) => @ids;
  my %foo = map { $_ => foo($_) } @ids;
[download]

But I don't know enough about how you'll use this function in practice to say anything about how you should do in your code. In particular, you might want to handle list calls because the DB access might benefit from that.

Hope I've helped,
ihb

Read argumentation in its context!